top - download
⟦30c95f711⟧ Wang Wps File
Length: 48663 (0xbe17)
Types: Wang Wps File
Notes: FXA/SDS/001, Issue 3 , Missing sectors
Names: »6012A «
Derivation
└─⟦b3c9a9699⟧ Bits:30006142 8" Wang WCS floppy, CR 0015A
└─ ⟦this⟧ »6012A «
WangText
…00……00……00……00……00…;…02……00……00…;
;…05…:…0a…: 9…0e…9…06…9…07…8…0d…8…01…8…05…7…09…7…0c…7…02…7…06…6…0b…6…0e…6 5…09…5…0a…5…0b…5…0c…5…0d…5…01…5 4…0b…4…02…3…0b…3…01…3…02…3…07…2…0c…2…02…2 1…09…1…0d…1…0e…1…01…1…07…0…86…1
…02… …02… …02…
…02… FXA/SDS/001 (3)
SYSTEM DESIGN SPECIFICATION…02… APE/851101…02……02…
FOR THE FIKS/FOD-CCIS LINK
…02… APE/840620…02… FIKS-FODCCIS
SYSTEM DESIGN SPECIFICATION
FOR THE FIKS/FOD-CCIS LINK
FXA/SDS/001
ALLAN PETERSEN
APE, REV, PBH, LU, NMC (6), FMK (2)
3
851101 …0f… …0f…
FXA/SDS/001 (3)
…02… APE/851101 2
SYSTEM DESIGN SPECIFICATION
FOR THE FIKS/FOD-CCIS LINK…02… APE/840620 …0e… FIKS-
FODCCIS…0f…
6012A/500A
Iss.1 840308 All Original
issue
of
document
------------------------------------------------------------------------
Iss.2 840620 Minutes of All Issue
2
of
document
with
Meetings with
a
3
byte
packet
840328,840409, header ZCZC + NNNN excluded
840503 from text and several minor
corrections.
------------------------------------------------------------------------
Iss.3 851101 All As-built
document
(final issue).
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
1 GENERAL ..........................................
7
1.1 SCOPE ........................................
7
1.2 INTRODUCTION .................................
7
1.3 APPLICABLE DOCUMENTS..........................
8
1.4 ABBREVIATIONS ................................
12
2 SUMMARY OF REQUIREMENTS ..........................
14
2.1 OPERATOR INTERFACE REQUIREMENTS ..............
14
2.2 SUPERVISORY LINK CONTROL .....................
15
2.3 HIGH LEVEL MESSAGE HANDLING ..................
16
2.3.1 Distribution of Messages, CCIS to FIKS ...
16
2.3.2 Dispatch of Messages, FIKS to CCIS .......
16
2.4 LEVEL 2 PROTOCOL REQUIREMENTS.................
17
2.5 USE OF V24 CIRCUITS ..........................
17
2.6 H/W ENVIRONMENT OF ONE FIKS/CCIS I/F .........
22
2.6.1 LTUX-M Front-End Module ..................
22
2.6.2 LTUX-M CPU Module ........................
22
2.6.3 Additional RAM Boards ....................
22
2.6.4 Fan Unit, Power Supply, Crate & Cables ...
22
2.7 PERFORMANCE REQUIREMENTS .....................
23
2.7.1 Nodes of Installation ....................
23
2.7.2 System Load and Bit Rates ................
23
3 PACKAGE SPECIFICATIONS ...........................
24
3.1 FIKS-CCIS LINK OVERVIEW ......................
24
3.1.1 FIKS-CCIS Data Interface .................
29
3.1.1.1 Narrative Messages from CCIS .........
29
3.1.1.2 Narrative Messages from FIKS to CCIS
. 30
3.1.1.3 Control Messages to/from CCIS ........
31
3.1.1.4 Other FIKS Data Interface Updates ....
33
3.1.2 FIKS-CCIS Link Protocols .................
36
3.1.2.1 FIKS-CCIS Link X25.3 Protocol ........
36
3.1.2.2 FIKS-CCIS Link Message Protocol ......
37
3.1.2.3 FIKS-CCIS Link Keep Alive Protocol ...
38
3.1.2.4 FIKS-CCIS Link Open/Close Protocol ...
39
3.2 CCIS-NODAL PROCESS (CNSS) ....................
41
3.2.1 Functional Capabilities ..................
41
3.2.2 CNSS Interface Description ...............
42
3.2.2.1 Interface Overview ...................
42
3.2.2.2 Format of AMOS Message/Answer
to/from CNSS .........................
44
3.2.2.3 CNSS Interface to the CCIS LTUX ......
45
Page
3.2.3 CNSS Processing ..........................
46
3.2.3.1 CNSS Main Flow .......................
46
3.2.3.2 CNSS Initialization ..................
49
3.2.3.3 Processing of Incoming Packet ........
50
3.2.3.4 Processing of Outgoing Packet ........
52
3.2.3.5 Error Handling .......................
54
3.2.4 CNSS Error Locations .....................
55
3.2.5 CNSS Notes ...............................
56
3.3 CCIS TERMINAL PROCESS (CTERM) ................
57
3.3.1 Functional Capabilities ..................
57
3.3.2 Interface Description ....................
59
3.3.2.1 Interface Overview ...................
59
3.3.2.2 Format of AMOS Message/Answer
to/from CTERM ........................
61
3.3.3 CTERM Processing .........................
62
3.3.3.1 CTERM Main Flow ......................
62
3.3.3.2 CTERM Initializing ...................
64
3.3.3.3 Processing of Control Messages .......
65
3.3.3.4 Processing of Narrative Messages .....
67
3.3.3.5 Processing of Supervisor Commands ....
70
3.3.4 CTERM Error Locations ....................
71
3.3.5 CTERM Notes ..............................
72
3.4 CCIS PRINTER PROCESS (CPIP) ..................
73
3.4.1 Functional Capabilities ..................
73
3.4.2 Interface Description ....................
73
3.4.2.1 Interface Overview ...................
73
3.4.2.2 Format of AMOS Message/Answer
to/from CPIP .........................
75
3.4.3 CPIP Processing ..........................
76
3.4.3.1 CPIP Main Flow .......................
76
3.4.3.2 CPIP Timing Control ..................
78
3.4.3.3 CPIP Initializing ....................
79
3.4.3.4 Processing of Narrative Messages .....
80
3.4.3.5 Processing of Control Messages .......
83
3.4.3.6 ACK/NACK - Monitoring ................
85
3.4.3.7 Keep Alive Supervision ...............
86
3.4.4 CPIP Error Locations .....................
87
3.4.5 CPIP Notes ...............................
88
3.5 CCISLTUX .....................................
89
3.6 FIKS SYSTEM UPDATES .........................
92
Page
4 QUALITY ASSURANCE.................................
93
4.1 Unit Test Procedures .........................
94
4.1.1 CNSS Unit Test ...........................
97
4.1.2 CTERM Unit Test ..........................
103
4.1.3 CPIP Unit Test ...........................
113
4.1.4 Miscellaneous FIKS Update Test ...........
121
4.1.5 CCISLTUX Unit Test .......................
123
4.2 FIKS INTEGRATION TEST PROCEDURES .............
141
4.2.1 FIKS System - CCISLTUX Interface .........
146
4.2.2 Open/Close FODCCIS Link Procedures .......
147
4.2.3 FIKS-FODCCIS Message Transmission ........
150
4.2.4 FODCCIS Addressing .......................
152
4.2.5 FODCCIS Queue Manipulation ...............
153
4.2.6 FODCCIS Terminal Manipulation ............
155
4.2.7 FODCCIS Retrieve of Messages .............
156
4.2.8 FODCCIS Distribution Procedures ..........
157
4.2.9 FODCCIS Message Journal/Log ..............
158
4.2.10 FODCCIS Link Failure/Recovey ............
159
4.2.11 FODCCIS Switchover/Restart ..............
160
4.2.12 FODCCIS Link Performance ................
162
4.3 FIKS-FODCCIS LINK ACCEPTANCE TEST PROCEDURES
. 164
4.3.1 X25 Level 1 + 2 HDLC/LAB Protocol ........
171
4.3.2 Packet Protocol (X25 level 3) ............
181
4.3.3 Message Protocol (level 4) ...............
184
4.3.4 Open/Close Link Procedures ...............
187
4.3.5 Adaption to the FIKS System ..............
191
4.3.6 Link Performance .........................
196
4.4 FODCCIS LINK FACTORY ACCEPTANCE TEST .........
199
A̲P̲P̲E̲N̲D̲I̲C̲E̲S̲:
A. FIKS SYSTEM COMMAND FILES/ESP-LOGS
A1. CR80 MODULE TEST
A1.5 CCISLTUX UNIT TEST
A2. FIKS INTEGRATION TEST
A3. FIKS-FODCCIS LINK ACCEPTANCE
1 G̲E̲N̲E̲R̲A̲L̲
1.1 S̲C̲O̲P̲E̲
This document provides a specification of requirements
and their implementation according to contract 7Y3010
between S]v`rnets Materiel Kommando (NMC) and Christian
Rovsing A/S (CR) concerning a data link between the
FIKS and FOD-CCIS system.
The document is identified in the contract as line
item 1, System Design I/F Control Documentation.
1.2 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
It has been decided to establish a point to point connection
between three nodes in the FIKS message switching system
and three nodes in the FOD-CCIS system.
At message level both systems use the FIKS message
format across the interface.
Link level information exchange is based on CCITT recommendations
X25 LAPB.
The CCIS message assembly/disassembly and CCIS link
control in FIKS is handled by new SW and FW packages.
The design approach has been to regard the CCIS link(s)
as terminal(s). This way any CCIS link may use the
usual FIKS functions for message transmission.
The number of changes in the existing FIKS subsystems
is kept as low as possible. However, the software for
message distribution, operator interface, message queuing,
and checkpointing in FIKS must be slightly modified
in order to handle the new CCIS link.
Messages are entered and delivered in FIKS SMF.
1.3 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
1.3.1 Contract number 7Y3010 between S[V@RNETS MATERIEL KOMMANDO
and CHRISTIAN ROVSING A/S concerning an interface between
FIKS and FOD-CCIS. Christian Rovsing A/S, 1983-05-16.
1.3.2 Definition of Line Items, HW Delivery, Project Schedule,
and Bidding Provisions, ENCLOSURE 1 to Reference 1.3.1
1.3.3 Technical Specification for the FIKS to FOD-CCIS link,
ENCLOSURE 3 to Reference 1.3.1.
1.3.4 Optional Final Integration, ENCLOSURE 4 to Reference
1.3.1.
1.3.5 Interface Definition for the FIKS to CCIS Link, LOGICA
Job 42.3607, April 1982. ENCLOSURE 5 to Reference 1.3.1
1.3.6 FIKS Data I/F Reference, FIX/0100/MAN/0004, Issue 3,
Christian Rovsing A/S, 1983-08-15.
1.3.7 CCITT Recommendations X25, Geneva 1980.
1.3.8 CCITT Recommendations X25, Mar del Plata 1968.
1.3.9 LTUX-M SYSTEM SW, User…08…s Manual, CSD/MIC/230/PSP/0017,
Issue 3, Christian Rovsing A/S, 1983-08-15.
1.3.10 LTUX-M SYSTEM SW, Product Specification, CSD-MIC/230/PSP/0017,
Issue 3, Christian Rovsing A/S, 1983-07-22.
1.3.11 CR80 AMOS I/O SYSTEM, Product Specification, CSS/006/PSP/006,
Issue 2 or later, Christian Rovsing A/S, 1980-03-14.
1.3.12 CR80 AMOS TDX DRIVER, Product Specification, Issue
5, CSS/314/PSP/0013, Christian Rovsing A/S, 1981-05-01.
1.3.13 LCFGEN, Users Manual, Issue 2, FIX/1000/USM/0001, Christian
Rovsing A/S, 1983-07-07.
1.3.14 X.25 LAPB (LTUX VERSION), ISSUE 1
SE-PRD/PSP/0111
1.3.15 CR80 LTU I/F, Functional Specification, Issue 5, CSS-MIC/040/FNC/0001.
1.3.16 FIKS SYSTEM PSP,
FIX/1000/PSP/0038
1.3.17 PIP Substem PSP, Issue 1,
FIX/1152/PSP/0075
1.3.18 Q-INIT Procedure PSP, Issue 1,
FIX/1200/PSP/0075
1.3.19 Checkpoint Subsystem PSP, Issue 1,
FIX/1100/PSP/0041
1.3.20 MDS Subsystem PSP, Issue 1,
FIX/1152/PSP/0062
1.3.21 Log Journal Monitor, Issue 1,
FIX/1256/PSP/0057
1.3.22 Send Report Monitor PSP, Issue 1,
FIX/1256/PSP/0092
1.3.23 TDX Device Configuration Product Specification, Issue
1, FIX/3232/PSP/0034
1.3.24 FIKS QACCESS MONITOR PSP, Issue 1
FIX/1256/PSP/0078
1.3.25 SFS Submodule PSP, Issue 1
FIX/1155/PSP/0093
1.3.26 MES Subsystem PSP, Issue 1
FIX/1164/PSP/0060
1.3.27 CR80 AMOS Kernel
CSS/302/PSP/0008
1.3.28 ESP System PSP, Issue 1
FIX/1105/PSP/0046
1.3.29 MTCB Monitor PSP, Issue 1
FIX/1256/PSP/0066
1.3.30 QACCESS Monitor PSP, Issue 1
FIX/1256/PSP/0081
1.3.31 LCFH Monitor PSP, Issue 1
FIX/1256/PSP/0055
1.3.32 CR80 AMOS TDX TEST SYSTEM
CSS/714/USM/0066, Issue 2
1.3.33 Overlay Monitor PSP
FIX/1256/PSP/0073
1.3.34 FIKS S/W Configuration Ctrl. Lib. Disc.
FIX/1000/EWP/0080
1.3.35 SWELL 80, Reference Manual
CSS/415/RFM/0002, Issue 5
1.3.36 CR80 AMOS, SWELL Compiler, User's Manual
CSS/415/USM/00047, Issue 2
1.3.37 CR80 AMOS, Linker, Reference Manual
CSS/416/RFM/0003, Issue 3
1.3.38 CR80 AMOS, Linker, User's Manual
CSS/416/USM/0048.
1.3.39 SPECTRON D-101 DATA SCOPE
Operators Manual, Revision 3, SEP 1983
(incl. D-101X DECODE/DISPLAY FACILITY
FOR BIT-ORIENTED PROTOCOLS)
1.3.40 FIKS TDX Firmware Release Control Logbook,
FIX/3031/LOG/0007
1.4 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
ACK Acknowledgement
AMOS Advanced Multiprocessing Operating System
BID1000 cryptographic equipment
CCIS Command Control Information System.
CCITT Committ} Consultatif International Telegraphique
et Telephonique
CHECKP Checkpoint Subsystem
CMD Command
CNSS CCIS Nodal Switch Subsystem
CPIP CCIS Printer Process
CPU Central Processing Unit
CR Christian Rovsing A/S af 1984
CTERM CCIS Terminal Process
DCE Data Circuit-terminating Equipment
DMA Direct Memory Access
DTE Data Terminal Equipment
FD Floppy Disk
FE Front End part of LTUX-M
FIFO First In First Out
FIKS Forsvarets Integrerede Kommunikations
System
FMS File Management System
HDB Historical Data Base
HDLC High Level Data Link Control (ISO version
X25 level 2)
HW Hardware
ID Identification
I/F Interface
I/O Input/Output
LCF LTUX Configuration File
LF Line Feed
LTUX Line Terminating Unit for the TDX System
MDS Message Distribution Subsystem
MEDE Message Entry and Distribution Equipment
MTCB Message Transition Control Block
NAK Negative Acknowledgement
Node Computer Equipment at a FIKS Site
NSS Nodal Switch Subsystem
NMC Navy Material Command
N/M Combined Node and MEDE
PCB Process Control Block
PDB Preparation Data Base.
PIP Printer Interface Process Subsystem
QACCESS Queue Monitor Procedures Subsystem
RAM Random Access Memory
RDF Routing Directory File
RX Receiver Direction Modem to LTUX
SAF Supervisory Automatic Functions Subsystem
SCC System Control Center
SFS Supervisory Functions Subsystems
SMF Simplified Message Format
SRS Storage and Retrieval Subsystem
SW Software
TBD To be Defined
TBS To be Supplied
TDX Time Divisioned Multiplexing
TX Direction of Transmission LTUX to Modem
V24/V28 CCITT Recommendations for Definitions
of Circuits used for Data Exchange between
DTE and DCE equipment.
VDU Video Display Unit
X25 CCITT Recommendations for Link Level Data
Exchange
Refer also to ref. 1.3.6, sec. 1.2.
2 S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 O̲P̲E̲R̲A̲T̲O̲R̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
A supervisory procedure for opening the CCIS link is
invoked by entering the command 'OPC' on the supervisor's
VDU in response to the 'PROC ̲' prompt.
Similarly, 'CLC' will close the CCIS link.
The results of activating procedures 'OPC' and 'CLC'
and results of using the link generates alarm texts.
Alarm texts in FIKS can be displayed when requested
by the operator.
Alarm texts concerning the CCIS link shall inform the
users of the following types of events:
CCIS OPEN OK/NOT OK
CCIS CLOSED OK/NOT OK
CCIS LINK FAILURE
Besides OPC and CLC the following supervisor procedures
are available:
DOT Display and Update ANO
DOI Display ANO Index
DQS Display Queue Status
RRT Reroute Terminal Traffic
RET Reestablish Terminal Traffic
RDT Retrieve and Distribute
ROQ Reorganize Queue
REQ Relocate Queue
DDT Distribute from Supervisor Queue
DAL Display Alarm Texts
2.2 S̲U̲P̲E̲R̲V̲I̲S̲O̲R̲Y̲ ̲L̲I̲N̲K̲ ̲C̲O̲N̲T̲R̲O̲L̲
Open (OPC) and close (CLC) commands are encoded as
AMOS messages and sent to the CCIS TERMINAL process
for execution.
Opening and closing the CCIS link must be indicated
in Critical Region 'CONFIG' which must reflect whether
a particular CCIS link is available or not.
The following control messages are to be included
Message ACK
Message NAK
Open Link Request
Open Link Agreement
Open Link Rejection
Close Link
Keep Alive
2.3 H̲I̲G̲H̲ ̲L̲E̲V̲E̲L̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
2.3.1 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲,̲ ̲C̲C̲I̲S̲ ̲t̲o̲ ̲F̲I̲K̲S̲
Message formatting and addresssing is done according
to FIKS/CCIS DATA I/F section 3.1.1.
Narrative messages are assembled at level 3 and enqueued
to the level 4 SW for checking and further distribution
within FIKS.
The message is stored on PDB by the MTCB monitor and
delivered to the CTERM process.
Higher protocol levels handle the following control
messages:
Message ACK
Message NAK
Keep Alive
Incoming messages are assembled by stripping of a three
byte packet header.
2.3.2 D̲i̲s̲p̲a̲t̲c̲h̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲,̲ ̲F̲I̲K̲S̲ ̲t̲o̲ ̲C̲C̲I̲S̲
A specific, new logical terminal is assigned for each
of the three CCIS links. The CCIS link must fulfil
the usual requirements to a FIKS terminal.
Messages entered at any MEDE in FIKS may be routed
to CCIS if the address specified designates a legal
CCIS link terminal address.
Message formatting and addresssing is done according
to FIKS/CCIS I/F Data section 3.1.1.
Messages are disassembled into packets of 128 bytes
and handed over to the X25-application residing in
the LTUX-M.
Each packet includes a three byte header containing
a more bit, and a logical channel no.
2.4 L̲E̲V̲E̲L̲ ̲2̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
As link level protocol the X.25 HDLC/LAPB protocol
as described in ref. 1.3.7 shall be used. See also
ref. 1.3.5, appendix A.
This protocol level is implemented together with level
1 in a CR80 LTUX-M TDX module.
The I/F between the LTUX-M microprocessor and the CR80
CPU is based on the use of the AMOS I/O System and
the AMOS TDX driver
The packet size across the interface is 130 bytes.
The data is organized as follows:
- up to 125 bytes of data
- 3 byte data packet header
- 2 bytes header containing commands
(see also fig. 3.1.1-1).
System parameters are:
7 = max. number of possible outstanding unacknowledged
frames
2 = max. number of retransmissions of one frame
when the primary timer T1 has expired
5 s = primary timer T1 defined in Recommendations
X25, i.e. the time span within which an
information frame is expected to be acknowledged.
0.5 s = secondary timer T2 defined by X25
2.5 U̲S̲E̲ ̲O̲F̲ ̲V̲2̲4̲ ̲C̲I̲R̲C̲U̲I̲T̲S̲
The V24-interface shall fulfil the requirements, that
can be derived from the figures 2.5-1, 2.5-2, 2.5-3
and 2.5-4.
FIGURE 2.5-1
FIGURE 2.5-2
Figure 2.5-3
Figure 2.5-4
2.6 H̲W̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲ ̲O̲F̲ ̲O̲N̲E̲ ̲F̲I̲K̲S̲/̲C̲C̲I̲S̲ ̲I̲/̲F̲
2.6.1 L̲T̲U̲X̲-̲M̲ ̲F̲r̲o̲n̲t̲-̲E̲n̲d̲ ̲M̲o̲d̲u̲l̲e̲
The LTUX-M FE interfaces the LTUX-M to the TDX bus.
System F/W is used for controlling assembly and dissasembly
of 16 bytes TDX packets sent between the FE and the
CR80 Host Interface module. The level 3 packets are
delivered to the LTUX-CPU via the microbus.
The LTUX-FE must be equipped with 6k PROM and 4k RAM.
2.6.2 L̲T̲U̲X̲-̲M̲ ̲C̲P̲U̲ ̲M̲o̲d̲u̲l̲e̲
The LTUX-M CPU runs the application FW containing the
HDLC protocol, TDX I/F, drivers, and operating system.
The LTUX-M CPU requires 16k PROM and 16k RAM.
2.6.3 A̲d̲d̲i̲t̲i̲o̲n̲a̲l̲ ̲R̲A̲M̲ ̲B̲o̲a̲r̲d̲s̲
It is foreseen that the new processes and FIKS subsystem
extensions will require an extra 16k RAM CR80 module
for each FOD-CCIS I/F installled.
2.6.4 F̲a̲n̲ ̲U̲n̲i̲t̲,̲ ̲P̲o̲w̲e̲r̲ ̲S̲u̲p̲p̲l̲y̲,̲ ̲C̲r̲a̲t̲e̲,̲ ̲a̲n̲d̲ ̲C̲a̲b̲l̲e̲s̲
Additional equipment is not provided by CR as stated
in Reference 1.3.2, p 5.
2.7 P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.7.1 N̲o̲d̲e̲s̲ ̲o̲f̲ ̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
The FOD-CCIS link is installed only at Node/MEDE's
without collocated SCC's.
The installation sites are assumed to be nodes A, F,
and N.
At these sites the LTUX-M's used for the CCIS link
have a set of usual V24 interfaces (Reference 1.3.5,
fig. 2.5-1 and 2.5-2.
For each site, strap fields and V24 timing diagrams
are provided by NMC.
2.7.2 S̲y̲s̲t̲e̲m̲ ̲L̲o̲a̲d̲ ̲a̲n̲d̲ ̲B̲i̲t̲ ̲R̲a̲t̲e̲s̲
The load from the incoming + outgoing message traffic
should not exceed a load corresponding to 200 signals
of 1000 characters per hour.
The transmission speed is 9600 baud.
3 P̲A̲C̲K̲A̲G̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
3.1 F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲L̲I̲N̲K̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
In the following is listed some of the elements/guide
lines/concepts involved in the design of the FIKS-CCIS
Link.
E̲x̲i̲s̲t̲i̲n̲g̲ ̲F̲I̲K̲S̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲r̲e̲f̲.̲ ̲1̲.̲3̲.̲1̲6̲)
The introduction of the FIKS-CCIS Link into the FIKS
System has been performed with a minimum of changes
in the existing FIKS Hardware/Software. The existing
operational procedures have not been changed. The design
of the FIKS-CCIS Link has, as far as possible, exploited
the existing FIKS Hardware/Software to minimize the
efforts to be used in the implementation.
F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
To handle level 1 + 2 of the protocol, X25.(1+2) HDLC/LAPB
recommended in ref. 1.3.7 has been used. In ref. 1.3.5
page 6 is stated that level 3 isn't necessary. A closer
analysis shows that this would be very inconvenient.
E.g. Returning of message acknowledge should await
end-of-transmission of a possible large message before
it could be despatched. Due to this and other things
it was found also suitable to use a message level protocol
with at least two logical channels. This also implies
that a packet level protocol shall be used. Therefore
a (minimum) subset of the X.25 (level 3 packet protocol
has been used to implement the link. Two logical message
channels are used, one for Control Messages and one
for Narrative Messages. Each message having a window
size equal 1.
The control channel will have the highest priority.
The link can be Opened/Closed for Narrative Message
Traffic by intervention from the supervisors at both
FIKS and CCIS. All other levels in the link shall
default be opened, if not inhibit by the hardware condition.
C̲C̲I̲S̲-̲T̲e̲r̲m̲i̲n̲a̲l̲
Seen from the FIKS System the CCIS System is regarded
as an ordinary MEDE-terminal. In this way needed procedures
for monitoring and supervision of the link can be executed
by using already existing procedures for use of ordinary
FIKS terminals, i.e.,
- The CCIS Terminal gets a set of terminal queues
(output queues). In this way the priority in the
despatch of message is fulfilled.
- The CCIS Terminal shall be of the type 'Recieve
only Printer'. Then it can be immediately added
to the existing terminal configuration and there
will be no need for development of the new 'initializing'
procedures.
- The CCIS Terminal will get an unique Terminal ID
and one or more ANO's pointing at the terminal.
In this way all addressing to CCIS is handled.
- The CCIS Terminal shall have a predetermined classification
and terminal operation type. That is used in the
security handling procedures.
- Almost any of the standard FIKS message/terminal
handling routines can immediately be used as:
Message Journal
Message Log
Alarm Procedures
Distribution Error Procedures
Supervisor Procedures -
DOT, DOI, DQS, RRT, RET, RDT,
ROQ, REQ, DDT, DAL
C̲C̲I̲S̲-̲N̲o̲d̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲(̲C̲N̲S̲S̲)̲ ̲r̲e̲f̲.̲ ̲s̲e̲c̲.̲ ̲3̲.̲2̲
This is a process running in the CR80. The CNSS is
mainly dealing with handling level 3+4 of the link
protocol. Both incoming and outgoing traffic is processed.
Incoming: Data packets received from CCIS are assembled
to one message. The message is placed in a PDB- file
and handed over to the CCIS Input Message Handler (CTERM).
Outgoing: A message placed in a PDB-file is received
from the CCIS output message handler (CPIP). The message
is disassembled into data packets and transmitted to
CCIS.
The CNSS shall be able to handle two logical channels.
The CNSS can be seen as 'driver' - process for the
CCIS Link. It shall therefore have high priority in
the CR80 processing and cannot be runned as a background
task. It must be a small process in size and demand
of CPU-time.
C̲C̲I̲S̲ ̲-̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲(̲C̲T̲E̲R̲M̲)̲ ref. sec. 3.3
This is a process running in the CR80. The CTERM process
handles all from CCIS incoming messages and checks
their validity and sees to that an ACK/NACK is returned
to CCIS.
Narrative messages are released to the FIKS System.
Control messages are handled by the CTERM itself. Supervisor
link commands are received and handled by the CTERM.
The CTERM- Process may be run as a background task
in the CR80.
C̲C̲I̲S̲ ̲-̲ ̲P̲r̲i̲n̲t̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲(̲C̲P̲I̲P̲)̲ ref. sec. 3.4
This is a process running in the CR80.
The CPIP Process handles all messages to be transmitted
to CCIS. It receives narrative messages from the FIKS
Network, checks and formats them before they are despatched
to CCIS. Control Messages are on request created and
transmitted to CCIS. The CPIP Process makes out the
message flow control to CCIS.
The CPIP Process may be run as a background task in
the CR80.
C̲C̲I̲S̲-̲L̲T̲U̲X̲ ̲ref. 1.3.14
This is a standard LTUX-M-FE, LTUX-M-CPU connected
to the red TDX-bus.
The software (firmware) implemented in this deals with
X25 level 1+2. The software consists of two parts.
A standard system software part and an application
software part. The application part is especially developed
for use at the FIKS-CCIS Interface but based upon similar
applications used in other CR-Systems.
The CCIS-LTUX is a very important element in the FIKS/
FODCCIS Link. Most of the functions, that it performs,
are described in other documents than this (FXA/SDS/001).
It is therefore receommended for persons, who is going
to work closely with the FIKS/FODCCIS link to procure
ref. 1.3.14 and 1.3.23.
M̲i̲s̲c̲e̲l̲l̲a̲n̲e̲o̲u̲s̲ ̲F̲I̲K̲S̲ ̲U̲p̲d̲a̲t̲e̲s̲ ̲(̲C̲M̲I̲S̲C̲)̲ ref. sec. 3.6.
By this means not already mentioned updates in the
FIKS-System that is needed to implement the FIKS-CCIS
Link.
The range of available FIKS-Supervisor Procedures is
expanded with 2 new:
OPC: Open CCIS Link
CLC: Close CCIS Link
This is performed by updating the FIKS Terminal Process.
The QACCESS ̲INIT Procedure (ref. 1.3.18 + 1.3.24) is
updated so that instead of giving the FIKS PIP Process
an AMOS SIGNAL at entry in the CCIS terminal printer
queues, then the CPIP-Process is given an AMOS SIGNAL.
The rest of the needed updating will only involve updating
of different parameters/table entries etc., used in
the FIKS System.
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲c̲o̲n̲c̲e̲r̲n̲i̲n̲g̲ ̲C̲C̲I̲S̲
In case of "Switchover" at the collocated Node/MEDE,
the CCIS-FIKS Link shall be reopened, if it was opened
before. As Switchover takes about 2 minutes, the CCIS
will declare the link for failed in this period. The
only way to reopen the link is therefore to issue an
OPC-command. This is performed automatically by the
subsystem as a part of the "Recover" procedure. This
means also that the status of the link shall be checkpointed.
All narrative messages to/from CCIS will be checkpointed
and recovered in the usual way and thereby assure that
they would not be lost in case of failure at the FIKS
side.
FIGURE 3.1-1
FIKS-CCIS LINK OVERVIEW
3.1.1 F̲I̲K̲S̲ ̲C̲C̲I̲S̲ ̲D̲a̲t̲a̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
This section deals with the data structures used in
the FIKS-CCIS Implementation and which is not already
defined in ref. 1.3.6 (to be included in ref. 1.3.6
at the time of FIKS-CCIS Link Integration in FIKS System).
3.1.1.1 N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲r̲o̲m̲ ̲C̲C̲I̲S̲
Those messages shall observe the Message Format defined
in ref. 1.3.6, sec. 10.1 with the following modifications/comments:
(The following points refer to those used in ref. 1.3.6,
sec. 10.1).
R̲e̲.̲ ̲1̲0̲.̲1̲.̲1̲ (Binary Header)
1) irrelevant
2) irrelevant
5) irrelevant
6) irrelevant
7) irrelevant
9) always 0 (no special handling)
13) always 0 (no readdressing)
16) irrelevant (FIKS will fill in)
R̲e̲.̲ ̲1̲0̲.̲1̲.̲2̲ (Signal Content)
- Line 1-Field D-Message ID
the FIKS-terminal ID assigned for the distinct
CCIS-FIKS link must be used
- Line 14, not present
- Line 15, not present
R̲e̲.̲ ̲1̲0̲.̲1̲.̲3̲ (Address List)
No modifications/comments.
3.1.1.2 N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲r̲o̲m̲ ̲F̲I̲K̲S̲ ̲t̲o̲ ̲C̲C̲I̲S̲
Those messages shall observe the Message Format defined
in ref. 1.3.6, sec. 10.1 with the following modification:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^
^ Binary ^
^ Header ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ Signal ^
^ Header ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ ^
^ Signal ^ Signal
^ Text ^
^ ^
^ ^
^ ^
^ ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ Signal ^ Line (14 + 15) sec. 10.1.2.
^ Tail ^ (release + retrieval time)
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ Address List ^
^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
After the last line in the original FIKS-message and
before the address list is inserted a "Signal-Tail".
This consists of two lines, Line 14 and Line 15 described
in ref. 1.3.6, sec. 10.1.2. Those lines are to be included
in the Signal Text. This means that the items "Message
Length" and "Address List Offset" in the Binary Header
have to be updated in connection with this insertion.
3.1.1.3 C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲t̲o̲/̲f̲r̲o̲m̲ ̲C̲C̲I̲S̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^ ^
^ Binary Header ^ FIKS Control Message Layout
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^
^ Control ^ ref. 1.3.6 sec. 10.2
^ Information ^ Ref. Binary Header: see below
^ (max. 32 words) ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
In the following is listed this information about those
items in the control message layout, that is used in
connection with the CCIS link.
(refer to 1.3.6, sec. 10.2)
- Main Type: always 2
- Precedence: equal 0 (superflash)
- Routing Mask: equal 0 (not used)
- Category: always 16
- Originator: If FIKS Node/MEDE then the
binary value of the ASCII
Node/MEDE-ID-#40.
If CCIS then the binary value
of the collocated Node/MEDE-ID-#20.
- Type May be one, of the following
Message Length, sets.
Control Information:
Type Message Length Control Information
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
1 40 'MESSAGE.ACK.CHANNEL.X',NL
2 42 'MESSAGE.NACK.CHANNEL.X.',NL
3 36 'OPEN.LINK.REQUEST',NL
4 38 'OPEN.LINK.AGREEMENT',NL
5 38 'OPEN.LINK.REJECTION',NL
6 30 'CLOSE.LINK.',NL
7 30 'I.AM.ALIVE.',NL
(Keep alive)
L̲e̲g̲e̲n̲d̲:
. : space character, decimal value 32
NL: New line character, decimal value 10
Re.Type 1+2: X may be either '0' - Control Channel
or '1'-Narrative Channel.
Type 3 can only be generated at FIKS
Type 4+5 can only be generated at CCIS.
Control Information is an even number of ASCII - characters
terminated with a NL-character (new line character)
3.1.1.4 O̲t̲h̲e̲r̲ ̲F̲I̲K̲S̲ ̲D̲a̲t̲a̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲U̲p̲d̲a̲t̲e̲s̲
C̲O̲N̲F̲I̲G̲ ̲U̲p̲d̲a̲t̲e̲ (ref. 1.3.6, sec. 5.1)
The items 43 + 44 in the Configuration Table CONFIG
shall be reserved for CCIS-STATUS and CCIS Logical
terminal number.
The value of CCIS-STATUS may be:
0: No FIKS-CCIS Link exists
1: FIKS-CCIS Link is CLOSED
2: FIKS-CCIS Link is OPENED
3: FIKS-CCIS Link is FAILED
If the FIKS-CCIS Link exists then
NO ̲OF ̲MESSAGE ̲TERMINAL in the QACCESS ̲PARAMETER ̲AREA
(Item no. 20 shall be incremented with one)
The logical CCIS terminal number will be the last one
in the MEDE configuration. I.e. one greater than the
last receive-only printer.
F̲I̲K̲S̲ ̲Q̲u̲e̲u̲e̲ ̲U̲p̲d̲a̲t̲e̲ ref. (1.3.6, sec. 6)
A set of terminal queues shall be reserved for use
of the FIKS-CCIS link. They shall be placed after the
last set of ordinary FIKS terminal queues. Signal module
shall be CPIP.
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲F̲i̲l̲e̲ ̲U̲p̲d̲a̲t̲e̲ (ref. 1.3.6, sec. 11.12)
Word 32 in the "System Checkpoint Area" shall be reserved
for checkpoint of the CCIS-STATUS. (Copy of the item
in CONFIG).
T̲C̲B̲ ̲U̲p̲d̲a̲t̲e̲ (ref. 1.3.6, sec. 7.2)
A TCB (Terminal Control Block) is sat up in the Critical
Region XTCBCR.
The items in the TCB is initialized as follows: (Items
not mentioned use standard values)
V ̲SID: 'CCIS' "User identification
N ̲RTERM: 0 "No release terminal
M ̲TMAP:#14 "PTP type + Release Auth.
M ̲TSTAT:#5 "Online + RX-Mode
U ̲MAP:#1 "Ordinary Message Preparator
K ̲USC: #B "CCIS Classification (Nato
Secret)
N ̲PTERM: 0 "No associated PTR
U ̲ANO : T.B.D "Nominal ANO
N̲e̲w̲ ̲N̲/̲M̲ ̲A̲l̲a̲r̲m̲ ̲T̲e̲x̲t̲s̲ (ref. 1.3.6, sec. 12.1.2)
'OPENING.OF.FOD.CCIS...........OK'
'OPENING.OF.FOD.CCIS...........NOT OK'
'CLOSING.OF.FOD.CCIS...........OK'
'CLOSING.OF.FOD.CCIS...........NOT OK'
'FOD.CCIS......................FAILURE'
Legend: . equals space character, decimal value 32
The texts are added to the end of the existing list.
FIGURE 3.1.1-1
MESSAGE/PACKET/FRAME LAYOUT
3.1.2 F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲L̲i̲n̲k̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
3.1.2.1 F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲L̲i̲n̲k̲ ̲X̲2̲5̲.̲3̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
(Packet Protocol)
Refer to fig. 3.1.1.1-1.
Two logical channels are used
- Control channel (for control messages)
- Narrative chananel (for narrative messages)
Packets belonging to one channel shall always be sent/received
in sequence.
Packets belonging to the narrative channel may be interrupted
by packets from the control channel. (The control channel
has the highest precedence).
No packet sequence numbering (in packet header) is
used.
Only data packets are used. First byte in the X25.3-header
must be 00010000 BIN. Other packet types shall be ignored.
3.1.2.2 F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲L̲i̲n̲k̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
FIKS/CCIS ^ ^ FIKS/CCIS
^ ^
^M̲e̲s̲s̲a̲g̲e̲ ^
^ A̲c̲k̲^ either
^ N̲a̲c̲k̲^ or
^M̲e̲s̲s̲a̲g̲e̲ ^
^ ^
Wait 20 ^ (nothing)^ or
seconds ^M̲e̲s̲s̲a̲g̲e̲ ^
^ ^
Two logical channels are used. Control channel for
control messages and narrative channel for narrative
messages. The control channel has the highest precedence
(ref. X25.3-protocol).
All types of messages that may pass across the link
are defined in sec. 3.1.1.(1+2+3). Other messages shall
be ignored.
All messages (Narrative- and Control-) except ACK's
and NACK's shall be acknowledged/not acknowledged on
logical channel 0 by use of ACK's and NACK's.
If a NACK is received then the message is retransmitted
until two times. (Message sent three times). If still
no ACK then the link is CLOSED. (Ref. Open/Close-protocol).
If neither ACK of nor NACK is received within a period
of 20 seconds, actions are taken as if a NACK were
received. i.e. retransmit message or close link.
On one channel the next message is not transmitted
before ACK is received on the previous. i.e. the message
window size equals one.
3.1.2.3 F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲L̲i̲n̲k̲ ̲K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
FIKS ^ ^ CCIS
^ ^
nothing ^ ^
transmitted ^ ^
20 sec. ^K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲ ̲ ^
^ ̲A̲C̲K̲ ̲ ̲^
^ ^
^ ^
If FIKS, while the link is open, not has been transmitted
something to CCIS in a period of 20 seconds counted
from reception of last received ACK/NACK, then it shall
send a Keep Alive Message to CCIS. FIKS expects to
receive an ACK on this message.
If CCIS does not receive anything from FIKS within
a period of 1 minute then it declares the link for
failed.
N̲o̲t̲e̲: (ref. message protocol)
If FIKS does not receive an ACK on the 'Keep Alive',
then it repeats it twice.
If still no ACK then it will declare CCIS for failed.
I.e. CCIS and FIKS will within the same period detects
a breakdown in the connection.
3.1.2.4 F̲I̲K̲S̲-̲C̲C̲I̲S̲ ̲L̲i̲n̲k̲ ̲O̲p̲e̲n̲/̲C̲l̲o̲s̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
FIKS ^ ^ CCIS
^ ^
^ O̲p̲e̲n̲ ̲L̲i̲n̲k̲ ̲ ^
^ Request ^
^ ̲A̲c̲k̲ ^
^ ^
^ ̲O̲p̲e̲n̲ ̲A̲g̲r̲e̲e̲^ either
Link Open ^ ^
^ A̲C̲K̲ ̲ ̲ ̲ ^ Link Open
^ ̲ ̲ ̲ ̲O̲p̲e̲n̲ ̲ ̲^ or
Link Closed ^ Rejection^
^ A̲C̲K̲ ̲ ̲ ̲ ^ Link Closed
^ ^
Wait 10 mins^ (nothing)^ or
^ ^
Link Closed ^ ^
O̲p̲e̲n̲i̲n̲g̲
FIKS/CCIS ^ ^ FIKS/CCIS
^ ^
^ C̲l̲o̲s̲e̲ ̲L̲i̲n̲k̲ ^
^ ^
Link Closed ^ ̲A̲c̲k̲ ̲ ̲^ Link Closed
^ ^
^ ^
^ ^
C̲l̲o̲s̲i̲n̲g̲
Link is O̲p̲e̲n̲ means:
Transmission of narrative mesages may be started. 'Keep
Alive' - traffic is maintained.
Link is C̲l̲o̲s̲e̲d̲ means:
No transmission of narrative messages may be started.
The going messages shall be finished. 'Keep Alive'
- traffic is stopped.
Link is F̲a̲i̲l̲e̲d̲ means:
No ACK/NACK is received (timeout).
R̲e̲ ̲O̲p̲e̲n̲i̲n̲g̲
Only FIKS can initiate an opening of the link. CCIS
can accept or reject the opening. FIKS will wait 10
minutes for answer upon the Open Link Request - a new
one will then be needed after this.
R̲e̲ ̲C̲l̲o̲s̲i̲n̲g̲
Both FIKS and CCIS can close the Link.
Closing procedures can be executed independent of the
state of the link (Open/Closed/Failed). Opening can
only be started (by FIKS) when the state of the link
is closed.
3.2 C̲C̲I̲S̲-̲N̲O̲D̲A̲L̲ ̲P̲R̲O̲C̲E̲S̲S̲ ̲(̲C̲N̲S̲S̲)̲
3.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The CNSS provides the packet level of the FIKS-CCIS
Interface Protocol. The packet level is implemented
as a subset of the X25-level 3 protocol as recommended
in ref. 1.3.7. The elements from the CCITT X25.3 protocol,
that are used, are those that are found to be necessary
to produce a well functioning FIKS-CCIS Interface.
The CNSS Process has the following tasks:
- Receive/deliver packets from/to the CCIS-LTUX.
This is performed using the FIKS TDX- system (i.e.
via the AMOS IO-system, TDX-driver, TDX-host, Red
TDX-bus).
- Handles the packets as belonging to two separate
logical channels (control, narrative channel).
The Control Channel will have the highest priority.
- Execute flow control to the CCIS-LTUX.
- Assemble incoming packets into a message and transfer
this to the CTERM-process (ref. 3.3).
- Receive messages from the CPIP-Process (ref. 3.4)
and disassemble those into outgoing packets.
- Initialize the CCIS-LTUX.
- Detect and report if the CCIS-LTUX fails.
3.2.2 C̲N̲S̲S̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
3.2.2.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
FIKS Interface, refer to 1.3.6
Refer to fig. 3.2.2.1
S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
1. FMS-System via the IO-system
2. TDX-System via the IO-system
3. Kernel, use of AMOS-message functions
F̲I̲K̲S̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲
1. FIKS Monitor Procedures -
MTCB (ref. 1.3.29).
C̲C̲I̲S̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲
1. CTERM-Process (delivery of messages)
2. CPIP-Process (reception of messages for transmission
to CCIS).
F̲i̲l̲e̲s̲
1. PDB-files.
FIGURE 3.2.2.1-1
CNSS INTERFACE OVERVIEW
3.2.2.2 F̲o̲r̲m̲a̲t̲ ̲o̲f̲ ̲A̲M̲O̲S̲ ̲M̲e̲s̲s̲a̲g̲e̲/̲A̲n̲s̲w̲e̲r̲ ̲t̲o̲/̲f̲r̲o̲m̲ ̲C̲N̲S̲S̲
Messages from CPIP requesting despatch of messages.
message answer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
^̲ ̲Channel ̲^̲ Word 0 ^̲ ̲ Channel ̲^̲
^̲ ̲MTCB index ̲^̲ 1 ^̲ ̲ MTCB index ̲^̲
^̲ ̲(of MTCB ̲^̲ 2 ^̲ ̲ ̲^̲
^̲ ̲referring to ̲^̲ 3 ^̲ ̲ ̲^̲
^̲ ̲m̲e̲s̲s̲a̲g̲e̲)̲ ̲ ̲ ̲ ̲ ̲^̲ 4 ^̲ ̲ ̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲ ̲^̲
Channel: Completion codes:
0: OK
-1: Link failure
0: Control Message returned when all
1: Narrative Message packets are 'appended'
to the TDX-system
The MTCB-layout used is as follows:
PSEUDO MTCB's (carrier of control messages)
(refer to ref. 1.3.6, sec. 7.1.2.1)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Category Subcategory BYTE 1 (not used)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
WORD 2 (not used)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
WORD 3 (not used)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
WORD 4 = message length
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
WORD 5 (not used)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
WORD 6 (not used)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
WORD 7 (not used)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Category = CCIS Category = 0
Subcategory = Control Message Type
(ref. sec. 3.1.1.3)
REAL MTCB's (carrier of narrative messages)
The only item used is the LENGTH-field
(ref. 1.3.6, sec. 7.1.1.1).
3.2.2.3 C̲N̲S̲S̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲t̲o̲ ̲t̲h̲e̲ ̲C̲C̲I̲S̲ ̲L̲T̲U̲X̲
Standard FIKS TDX System procedures are used.
The exchange of packets, formatted as described in
ref. 1.3.14, sec. 3.1.2.5 (5 + 6), is performed using
the standard AMOS I/O procedures:
INITREADBYTES (from CCIS LTUX to CNSS)
INITAPPENDBYTES (from CNSS to CCIS LTUX)
WAITOPERATIONS (reception of completion)
The initialization of the CCIS-LTUX is accomplished
by use of the procedures described in ref. 1.3.23
(TDX device configuration) and ref. 1.3.14
(X.25.2 link commands).
3.2.3 C̲N̲S̲S̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.2.3.1 C̲N̲S̲S̲ ̲M̲a̲i̲n̲ ̲F̲l̲o̲w̲ (ref. figure 3.2.3-1)
CNSS passes through an initializing phase, that mostly
deals with the initializing of the CCIS ̲LTUX. (ref.
3.2.3.2). After this, the kinds of events to initiate
some processing is awaited. They may be:
1) Reception of 'Despatch Commands'.
Those are issued by the CPIP-process as AMOS-messages
with layout defined in sec. 3.4.2.2. The commands
can indicate transmission of messages on both the
control channel and the narrative channel. Transmission
on the narrative channel can be interrupted of
transmission on the control channel (ref. sec.
3.1.2.1). At the moment when CNSS is going to read
from its AMOS-event queue, this one can contain
despatch commands destinated for both the control
and the narrative channel. The CNSS processing
must ensure that the control channel is served
first. This is performed as follows:
If the AMOS-message refers to use the control channel
then processing is immediately started. If it refers
to use of the narrative channel, then the next
message (if any) is read to see, if that one refers
to the control channel. If so, this one is processed
first, if not, the next AMOS-message is read etc.
The AMOS-messages not used are stored in the AMOS-message
'Save event' - queue for later retrieval and processing.
The 'Saved events' are recovered each time a message
has been processed (ref. 3.2.3.3). Each time a
packet has been processed (IO-APPEND-COMPLETION)
it is checked if a despatch 'control message command'
has arrived to CNSS and therefore shall be processed
immediately and before the packets belonging to
the rest of a possible narrative message being
processed.
FIGURE 3.2.3.1-1
MAINFLOW CNSS
2) Input from the CCIS-LTUX
This event is obtained as an (IO,INITREAD) - completion
from the IO-system (ref. 1.3.11).
The response can be:
- A LINK EVENT, ref. 1.3.14, sec. 3.1.2.5.4 informing
about link status changes.
In case this indicates 'link unavailability'
actions are taken described in sec. 3.2.3.5
- Error Handling.
- A TX-completion, ref. 1.3.14, sec. 3.1.2.5.5.
An 'Outgoing Packet' has been acknowledged by
CCIS. The CCISLTUX has by this got a buffer
released and is ready to accept a new data packet
from the CNSS. This is used by the CNSS to control
the flow to the CCISLTUX. An 'Outstanding Packet
Counter' (OPC) is maintained. The OPC is incremented
at dispatch of a data packet (ref. sec. 3.2.3.4)
and decremented at reception of a TX-completion.
No data packets are dispatched unless the OPC
is below a maximum value, i.e. 'LTUX NOT BUSY'.
- A data packet received from CCIS - ref. sec.
3.2.3.3.
3) IO-APPEND - completion
When a packet is despatched to CCIS (ref. 3.2.3.4)
it is performed by using MON(IO,INITAPPEND). The
completion of this operation informs the packet
is transferred to the LTUX, and therefore the corresponding
buffers in the CR80 can be released. A new MON
(IO,INITAPPEND) may then be performed (OUTPUT NOT
BUSY).
3.2.3.2 C̲N̲S̲S̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
As the FIKS MTCB-monitor is going to be used, MTCB
̲INIT is performed. ref. 1.3.24.
CNSS is responsible for initializing of the CCISLTUX.
The initialization is done in a way that makes no assumption
of the former state of the LTUX. I.e. the same procedure
can be used at all kinds of starts - cold START (after
MASTER-CLEAR), RESTART (at SWITCHOVER) or after local
failure (LOCAL ̲FIX ̲UP).
By use of the AMOS I/O Interface (ref. 1.3.11) two
logical channels (LOG LINEs) are CREATED to the TDX-driver
(ref. 1.3.12). One to SUBDEVICE 0 and one to SUBDEVICE
3. SUBDEVICE 0 is default OPEN and can therefore immediately
be used to OPEN SUBDEVICE 3 (ref. 1.3.23). The CCISLTUX
has now been initialized concerning the use of the
TDX-system. All communication between the CNSS and
the X25-application takes place via SUBDEVICE 3.
The X25-protocol is then initialized. This is performed
by use of the X25 Control Commands defined in ref.
1.3.14 as follows:
- A LINES DOWN COMMAND is issued.
This will in case of LINK UP also execute LINK
DOWN COMMAND. When the command has been performed
no X25 control commands from the CCIS-side (open
requests) can influence the FIKS-side processing.
- A CLOSE COMMAND is issued.
This will ensure effective clean-up of all buffers
used at the X25-processing. The CCISLTUX is now
clear and well-defined and controlled start of
the X25-protocol can take
