top - download
⟦5efe18d5a⟧ Wang Wps File
Length: 68718 (0x10c6e)
Types: Wang Wps File
Notes: FIX/1154/PSP/0107
Names: »3141A «
Derivation
└─⟦507b19fd6⟧ Bits:30006135 8" Wang WCS floppy, CR 0282A
└─ ⟦this⟧ »3141A «
WangText
O…00……00……00……00…I…02……00……00…I
H…0d…=…08…=
<…0d…<…06…;…0e…;
;…07…:…0b…:…0f…:
:…07…9…0a…9…0c…9…0d…9…01…9…05…8…0b…8…00…8 7…0a…7…0d…7…0f…7…06…6…0b…6…0c…6…0d…6…02…6
5…09…5…0d…5…0e…5…01…5…86…1 …02… …02… …02…
…02…FIX/1154/PSP/0107
…02… JL/821210…02……02…
NODAL SWITCH SUBSYSTEM (NSS)
…02……02…FK 7809
LIST OF CONTENTS
1 SCOPE ..................................................
1
1.1 Introduction .......................................
1
1.2 Abbreviations ......................................
3
1.3 Definition of Terms ................................
4
2 APPLICABLE DOCUMENTS ...................................
8
3 MODULE SPECIFICATION ...................................
10
3.0 Symbols ............................................
10
3.1 Functional Capabilities ............................
11
3.1.1 Transmisson between Nodes ......................
13
3.1.1.1 The Error-Free Transmissio .................
13
3.1.1.2 Close Trunk ................................
14
3.1.1.3 Open Trunk .................................
14
3.1.1.4 Transient Trunk Failure ....................
15
3.1.1.5 Permanent Trunk Failure ....................
16
3.1.1.6 Node Failure ...............................
19
3.1.2 Multiaddressing ................................
20
3.1.3 Flow control ...................................
23
3.1.3.1 Routing control ............................
23
3.1.3.2 Traffic Control ............................
26
3.1.3.3 Congestion Control .........................
28
3.1.4 Error Control ..................................
28
3.1.4.1 Physical Level .............................
28
3.1.4.2 Link Level .................................
29
3.1.4.3 Packet Level ...............................
29
3.1.4.4 Message Level ..............................
31
3.1.4.5 Node-To-Node Level .........................
31
3.1.4.6 Error Reporting ............................
31
3.1.5 Statistics .....................................
33
3.1.6 Network Control ................................
33
3.1.7 Start and Restart ..............................
34
3.1.7.1 Responsibility .............................
34
3.1.7.2 Checkpoints ................................
35
3.1.7.3 Restart ....................................
37
3.1.7.4 Recovery ...................................
37
3.1.7.5 Start ......................................
37
3.2 Interface Description ..............................
38
3.2.1 The MEDE .......................................
41
3.2.2 The SIP ........................................
43
3.2.3 The SCC ........................................
43
3.2.4 The Trunks .....................................
43
3.2.5 The Data Users .................................
49
3.2.6 The Timer Process ..............................
49
3.2.7 The Purge Process ..............................
49
3.2.8 The Checkpoint Process .........................
50
3.3 Processing .........................................
50
3.3.1 The Modules of NSS .............................
50
3.3.2 The Coroutine Monitor ..........................
52
3.3.3 Initialization .................................
54
3.3.3.1 Node Start .................................
56
3.3.3.2 Node Restart ...............................
57
3.3.4 The Packet Handler Module ......................
58
3.3.4.1 General Packet Handling ....................
58
3.3.4.1.1 Introduction .............................
58
3.3.4.1.2 Protocols ..............................
59
3.3.4.1.2.1 The Application Interface ............
59
3.3.4.1.2.2 The LTUX Protocol ....................
59
3.3.4.1.2.3 The X.25 Level 3 Protocol ..........
62
3.3.4.1.3 Packet Format ..........................
62
3.3.4.1.4 Semaphores between Submodules ..........
67
3.3.4.1.5 Start, Restart, Checkpoints ............
69
3.3.4.2 Inbound Packet Handling ....................
69
3.3.4.2.1 Functions ..............................
69
3.3.4.2.2 Operations .............................
70
3.3.4.2.3 Processing .............................
71
3.3.4.2.4 Size ...................................
71
3.3.4.2.5 Timing .................................
77
3.3.4.3 Outbound Packet Handling ...................
77
3.3.4.3.1 Functions ..............................
77
3.3.4.3.2 Operations .............................
79
3.3.4.3.3 Processing .............................
81
3.3.4.3.4 Size ...................................
90
3.3.4.3.5 Timing .................................
91
3.3.4.4 Packet-I/O .................................
91
3.3.4.4.1 Functions ..............................
91
3.3.4.4.2 Operations .............................
92
3.3.4.4.3 Processing .............................
93
3.3.4.4.3.1 The Input Coroutine ................
93
3.3.4.4.3.2 The Output Coroutine ...............
96
3.3.4.4.4 Size ....................................
98
3.3.4.4.5 Timing ..................................
98
3.3.5 The Transport Station Module ...................
99
3.3.5.1 General Message Handling ...................
99
3.3.5.1.1 Introduction ...........................
99
3.3.5.1.2 Protocol ...............................
101
3.3.5.1.3 Types of Messages ......................
104
3.3.5.1.4 Semaphores/Queues between Submodules
... 109
3.3.5.1.5 Use-Counters and Message Processing
.... 111
3.3.5.1.6 Start, Restart, Checkpoints ............
114
3.3.5.2 Inbound Message Transport ..................
115
3.3.5.2.1 Functions ..............................
115
3.3.5.2.2 Operations .............................
117
3.3.5.2.3 Processing .............................
119
3.3.5.2.4 Size ...................................
125
3.3.5.2.5 Timing .................................
125
3.3.5.3 Outbound Message Transport .................
125
3.3.5.3.1 Functions ..............................
125
3.3.5.3.2 Message Routing ........................
129
3.3.5.3.3 Operations .............................
133
3.3.5.3.4 Processing .............................
135
3.3.5.3.5 Size ...................................
143
3.3.5.3.6 Timing .................................
143
3.3.6 The Monitoring Module ..........................
143
3.3.6.1 Introduction ...............................
143
3.3.6.2 Messages Generated .........................
147
3.3.6.3 LTUX Supervision ...........................
150
3.3.6.3.1 Commands ...............................
151
3.3.6.3.2 Command Responses ......................
152
3.3.6.3.3 Status Requests ........................
153
3.3.6.3.4 Status Reports .........................
153
3.3.6.3.4.1 Trans ..............................
153
3.3.6.3.4.2 Trunk ..............................
154
3.3.6.3.4.3 NPDN ...............................
155
3.3.6.3.4.4 Data User ..........................
157
3.3.6.3.4.5 Red Crypto .........................
158
3.3.6.3.4.6 Black Crypto .......................
159
3.3.6.4 Neighbor Node Supervision ..................
159
3.3.6.5 Start, Restart, Checkpoints ................
161
3.3.6.6 Functions ..................................
162
3.3.6.7 Operations .................................
163
3.3.6.7.1 Operations for the Semaphore: MON .......
164
3.3.6.7.2 Operations for the Semaphore: MOND
...... 169
3.3.6.8 Processing .................................
170
3.3.6.9 Size .......................................
176
3.3.6.10 Timing ....................................
176
3.3.7 The Control Module .............................
176
3.3.7.1 Introduction ...............................
176
3.3.7.2 Message Received ...........................
177
3.3.7.3 Start, Restart, Checkpoints ................
179
3.3.7.4 Functions ..................................
179
3.3.7.5 Operations .................................
180
3.3.7.6 Processing .................................
181
3.3.7.7 Size .......................................
183
3.3.7.8 Timing .....................................
183
3.3.8 The Event Module ...............................
184
3.3.8.1 Introduction ...............................
184
3.3.8.2 Event Format ...............................
184
3.3.8.3 Semaphores and Operations ..................
185
3.3.8.4 Start, Restart, Checkpoints ................
186
3.3.8.5 Functions ..................................
186
3.3.8.6 Processing .................................
187
3.3.8.7 Size .......................................
189
3.3.8.8 Timing .....................................
189
3.3.9 The Starting Module ...........................
.189
3.3.9.1 Start/Restart ..............................
189
3.3.9.2 Functions ..................................
190
3.3.9.3 Operations .................................
190
3.3.9.4 Processing .................................
191
3.3.9.5 Size .......................................
192
3.3.9.6 Timing .....................................
192
3.3.10 The Checkpointing Rate ........................
192
3.3.10.1 Narrative Messages ........................
192
3.3.10.2 Control Messages ..........................
195
3.3.10.3 Total Rate ................................
195
3.3.11 Timers and Retransmissions ....................
197
3.3.11.1 The Link Level ............................
197
3.3.11.2 The Packet Level ..........................
198
3.3.11.3 The Message Level .........................
199
3.3.11.4 The Network Level .........................
199
3.3.12 Open/Close Trunk ..............................
200
3.3.13 NPDN Call-up and Close-down ...................
207
3.4 Data Organization ..................................
210
3.4.1 Levels of Data .................................
210
3.4.2 The Data Bases .................................
212
3.4.2.1 The Preparation Data Base ..................
212
3.4.2.2 The Historical Data Base ...................
212
3.4.2.3 The Intermediate Message File ..............
212
3.4.2.3.1 The Size of the IMF ....................
215
3.4.2.4 The Nodal Data File ........................
221
3.4.2.5 The Jack File ..............................
223
3.4.2.6 The Checkpoint File ........................
225
3.4.2.7 The LTUX Configuration Files ...............
227
3.4.3 Queues .........................................
227
3.4.3.1 Queue Lengths and Waiting Times ............
228
3.4.3.2 The Transport Queue ........................
229
3.4.3.2.1 Requirements ...........................
229
3.4.3.2.2 Design .................................
231
3.4.3.2.3 Usage ..................................
234
3.4.3.3 The Control Queue ..........................
235
3.4.3.4 The MDS Queue ..............................
236
3.4.3.5 The CIP Queue ..............................
237
3.4.3.6 The SIP Queue ..............................
237
3.4.3.7 The Trunk Queue ............................
237
3.4.3.8 The Purge Queue ............................
243
3.4.3.9 Reservation of Queue Element ...............
243
3.4.4 Buffers ........................................
245
3.4.4.1 The Pool of Packet Buffers .................
245
3.4.4.2 The Cyclic Input Buffer ....................
248
3.4.4.3 The Outbound Message Buffer ................
251
3.4.5 Tables .........................................
254
3.4.5.1 The I/O-Transfer Table .....................
254
3.4.5.2 The Message/Answer Table ...................
256
3.4.6 Semaphores and Operations ......................
258
3.4.6.1 General Lay-out of Operations ..............
260
3.4.7 Constants and Variables ........................
261
3.5 Storage Allocation ................................
262
3.5.1 Memory Space Requirements .....................
262
3.5.1.1 Program and Data ..........................
262
3.5.1.2 Message Buffers ...........................
266
3.5.1.3 File Descriptions .........................
268
3.5.1.4 I/O-Control Blocks ........................
270
3.5.1.5 Transfer List Elements ....................
270
3.5.2 Disc Space Requirements .......................
271
3.6 Performance Characteristics .......................
272
3.6.1 Equation of Continuation ......................
272
3.6.2 Node Traffic ..................................
275
3.6.2.1 Narrative Messages ........................
275
3.6.2.2 Control Messages ..........................
280
3.6.2.3 ACK/NACK's ................................
280
3.6.3 Timing of NSS Execution .......................
281
3.7 Limitations .......................................
284
3.8 Error Codes/Error Locations .......................
285
3.8.1 Kernel ........................................
285
3.8.2 LTUX I/O ......................................
285
3.8.3 QACCESS .......................................
286
3.8.4 MTCB-Monitor ..................................
286
3.9 Listing References ................................
286
4 QUALITY ASSURANCE .....................................
287
4.1 Qualification Tests ...............................
287
4.2 Other Quality Assurance Provisions ................
287
5 PREPARATIONS FOR DELIVERY .............................
288
6 NOTES .................................................
290
7 APPENDICES ............................................
291
7.1 The Length of Messages ............................
291
7.2 The NSS in the System Control Centers .............
295
1. S̲C̲O̲P̲E̲
1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This document specifies t̲h̲e̲ ̲N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ within the FIKS application software.
The design is based on issue 5 of the Requirements Specifications.
The slightly modified version of the NSS used in the SCC's is described in Appendix 7.2.
The main tasks of the NSS are:
- the receipt of messages from the local MEDE and a possible collocated SCC; these messages
are forwarded through the network.
- the receipt of message packets from the network; the messages are sent to the local MEDE
and a possible SCC or they are relayed.
- routing of messages.
- assembly of inbound packets into messages before routing, and disassembly of outbound
messages into packets after routing.
- queueing by precedence of outbound messages.
- Node-to-Node message control.
- copying of multiaddress messages.
- oscillation and looping control.
- SCC- and MEDE-communication for error- and statistical reporting and for the receipt of
network controllig information.
The network is a message switching network (fig. 1.1-1).
1.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
CCITT Comit} Consultatif International Telegraphique et Telephonique
CIP Collocated N/M Interface Process
CTR Control
HDB Historical Data Base
HDLC High Level Data Link Control
IMF Intermediate Message File
LTUX Line Terminating Unit for the TDX-bus
MDS Message Distribution Subsystem
MTCB Message Transition Control Block
NDF Nodal Data File
NPDN Nordic Public Data Network
NSS Nodal Switch Subsystem
OMB Outbound Message Buffer
PDB Preparation Data Base
PGE Purge
SCC System Control Center
SFS Supervisory Functions Subsystem
SIP SCC Interface Process
TDX Time Divisioned Multiplexing
TRK Trunk
TRP Transport.
1.3 D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲r̲m̲s̲
ADAPTIVE ROUTING Routing i̲n̲f̲l̲u̲e̲n̲c̲e̲d̲ ̲b̲y̲ changes of the network topology, local congestion,
and changes of the (average long term) load.
ALTERNATE ROUTING A̲l̲t̲e̲r̲n̲a̲t̲e̲ ̲r̲o̲u̲t̲e̲s̲ are calculated together with the normal one, and used
when the latter is not available.
CHANNEL 1. A logical channel in X.25.
2. A data channel in the LTUX; several channels may share a trunk.
3. A crypto channel in the crypto equipment.
CHECKPOINT A state of a subsystem from which r̲e̲s̲t̲a̲r̲t̲ may be performed.
The State Variables necessary for a possible restart are saved outside
the system.
COMMUNICATION LINE A line between a node and a data user, or from a MEDE to a Comcenter
with terminals, or between SCC and NICS-TARE.
CONGESTION A network state in which an increased demand produces n̲o̲ ̲i̲n̲c̲r̲e̲a̲s̲e̲ in
throughput.
COPY OF A MESSAGE The network produced copy of a message; one copy is produced for each
destination. See "multiplicity".
COROUTINE A piece of code, which is executed in parallel with other coroutines,
w̲i̲t̲h̲o̲u̲t̲ ̲b̲e̲i̲n̲g̲ ̲i̲n̲t̲e̲r̲r̲u̲p̲t̲e̲d̲ between two waiting points.
CRASH Stop or serious malfunction of a system, so that the take-over of its
functions by its standby system is mandatory.
CRASH TIME The time when a computer c̲r̲a̲s̲h̲e̲s̲. This time is common to all s̲u̲b̲s̲y̲s̲t̲e̲m̲s̲
of the computer immediately after the last checkpoint of any of its
subsystems.
LOG-LINE A TDX-driver term which enables several simultaneous data- and control
paths to and from one LTUX.
LOGICAL CHANNEL An X.25 level 3 term which enables several silmultaneous virtual calls
and permanent virtual circuits.
LOOPING The arrival of a message at a node, already passed (also called oscillation,
orbiting).
MULTIPLICITY The multiplicity of the network is defined as the fraction:
DEST…0f…n…0e… ORIG…0f…n…0f…
all nodes all nodes
i.e. Number of incoming messages/Number of outgoing messages within
some period of time, or in other words: the amount of copying performed
by the nodes because of the multiaddress option for narrative messages.
PHANTOM MESSAGE An unnecessary (but accepted) copy of a message. May f.ex. be produced
when an ACK is lost.
PREDETERMINED ROUTING
The route of a message is determined before it is put into the network.
RECOVERY The reprocessing of c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ data performed after restart.
RESTART Initialization of a s̲t̲a̲n̲d̲b̲y̲ ̲s̲y̲s̲t̲e̲m̲ after a c̲r̲a̲s̲h̲.
ROUTE 1. A line through the network from the originating node to the destination
node via trunks and possible intermediate nodes. Not necessarily
the optimum route.
2. A line through the network via trunks and nodes followed by a data
user from origin to destination.
ROUTING Determination of the optium route or part hereof for a message.
START The very first initialization of a system.
TRUNK Synchronous, full duplex, 9.6 kbaud line between two nodes, or between
an SCC and the collocated node. It may be permanent or called up (via
NPDN).
TRUNK GROUP Two or more trunks between a pair of nodes.
WINDOW The number of consecutive data packets authorized to cross the interface
(X.25 level 3).
X.25 CCITT recommendation describing the interface between a DTE and a DCE
for terminals operating in the packet mode on public data network.
2. A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
1. REQUIREMENTS SPECIFICATION
FIX/0000/SPC/0002
Vol. I - III, issue 5, 800310
2. FIKS SYSTEM DESIGN SPECIFICATION
FIX/1000/DSP/0001
issue 5, 800507
3. FIKS SOFTWARE INTERFACE REFERENCE
FIX/0100/MAN/0003
Issue 2, 800530
4. FIKS DATA INTERFACE REFERENCE
FIX/0100/MAN/0004
Issue 2, 800530
5. SUPPORT SOFTWARE DESIGN SPEC.
FIX/1103/DSP/0009
Issue 1, 800430
6. CR 80 AMOS KERNEL
CSS/302/PSP/0008
Issue 2, 810303
7. CR 80 AMOS, I/O SYSTEM
CSS/006/PSP/0006
Issue 3, 810401
8. CR FILE SYSTEM PSP
CSS/910/EWP/0001
Issue 2, 790226
9. CR 80 TDX DRIVER
CSS/314/PSP/0013
Issue 5, 810501
10. FIKS TDX SYSTEM DESIGN SPECIFICATION
FIX/3131/DSP/0011
Issue 3, 800606
11. CCITT YELLOW BOOK
VOLUME VIII.2
DATA COMMUNICATION NETWORKS - X.25
Geneva 1980
12. TEST REPORT FOR THE NSS
VOLUME I - III
FIX/1154/TRP/0092
3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
The functions of the NSS are:
a. TRANSMISSION:
- Transmission of packets from node to node
- Disassembly/assembly of messages/packets
- Temporary storage of messages on disc
- Exchange messages with the local MEDE and a possibly collocated SCC.
b. MULTIADDRESSING:
- Copying of messages for multiple MEDE-addresses.
c. FLOW CONTROL:
- Routing Control: Routing of messages by means of Routing Tables.
Switching from secondary to primary route of data users.
- Traffic Control: To give higher priority to relay messages than messages entering
the network, and higher priority to incoming messages than to relay
messges.
Queue administration.
- Congestion or Priority Control:
The internal queues are handles by precendence level.
d. ERROR CONTROL:
- Physical Level
- Link Level
- Packet Level
- Mesage Level
- Node-to-Node Level
- Error reporting
e. NETWORK SUPERVISION
- Receipt and processing of controlling information from the MEDE- and from the SCC
- supervisors.
- Monitoring and forwarding reports for the MEDE - and the SCC supervisors.
f. STATISTICS
- Maintain tables of statistical information.
- Forward statistical information to the SCC.
g. START AND RESTART
- Checkpoint -saving queues, buffers and other
information necessary for restart.
- Recovery -reprocessing of checkpoint data after restart.
- Start -start based on initial data, i.e. the initial start is treated as a
special case of restart.
3.1.1 T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲B̲e̲t̲w̲e̲e̲n̲ ̲N̲o̲d̲e̲s̲
3.1.1.1 T̲h̲e̲ ̲E̲r̲r̲o̲r̲f̲r̲e̲e̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
During the errorfree t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ messages are transferred between a̲ ̲p̲a̲i̲r̲ ̲o̲f̲ ̲n̲o̲d̲e̲s̲ via a
t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲l̲i̲n̲e̲ in b̲o̲t̲h̲ ̲d̲i̲r̲e̲c̲t̲i̲o̲n̲s̲.
When a message is received, it is acknowledged by returning an ACK to the sending node.
The purpose of this is to maintain f̲l̲o̲w̲ ̲c̲o̲n̲t̲r̲o̲l̲, that is to ensure that messages are not
forwarded faster than the receiver is always able to accept the messages. For identification
each message is supplied with a unique number. Another advantage of the ACK will be mentioned
when talking about NODE - MEDE Restart, (Chapter 3.1.1.6). Before being transmitted a message
is chopped into p̲a̲c̲k̲e̲t̲s̲. The purpose of this is to obtain e̲a̲s̲i̲e̲r̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲, because messages
may be extreme long. Another purpose is to give p̲r̲i̲o̲r̲i̲t̲y̲ to the messages: if during transmission
of a message another message of higher priority must be transmitted, the first message is
temporarily aborted, and transmission of the last message is initiated; also this message
may be temporarily aborted, if meanwhile, a third message of even higher priority must be
transmitted and so on. (As an example short messages could be given a higher priority than
long messages reducing the average delay). A third reason for chopping a message into packets
will be mentioned in connection with transmission errors and retransmission ( chapter 3.1.1.4).…86…W
…02… …02… …02… …02… …02… …02…
3.1.1.2 C̲l̲o̲s̲e̲ ̲T̲r̲u̲n̲k̲
When a trunk is closed it must not be used for message traffic (but it should still be used
for data user traffic) until it is reopened.
After a "close trunk" command the trunk state is set to closed.
All messages outbound on the trunk (and not yet acknowledged) must be rerouted.
All messages inbound on the trunk and only partly received must have their resources released.
The messages will be rerouted by the sender.
Probably there will now exist a mismatch between the packet - as well as the message numbers
of the two nodes. Therefore they must be brought to agree, when the trunk is opened.
See also ch. 3.3.12 for more detailed information.
3.1.1.3 O̲p̲e̲n̲ ̲T̲r̲u̲n̲k̲
In both neighbours the inbound - as well as the outbound packet numbers and message numbers
are reset, because there may exist a mismatch from the previous disconnection or closing
of the trunk.
The trunk state is set to open, so message - traffic is allowed to flow.
See also ch. 3.3.12 for more detailed information.…86…W …02… …02… …02… …02… …02… …02…
3.1.1.4 T̲r̲a̲n̲s̲i̲e̲n̲t̲ ̲T̲r̲u̲n̲k̲ ̲F̲a̲i̲l̲u̲r̲e̲
If noise or another t̲r̲a̲n̲s̲i̲e̲n̲t̲ ̲t̲r̲u̲n̲k̲ ̲f̲a̲i̲l̲u̲r̲e̲ disturbs the transmission of a packet, the failure
will be detected (with a very high degree of probability) at the receiving node, and the
erroneous packet will be discarded.
The packet may be r̲e̲t̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ until it is received without error.
Let p: Probability of error per bit
H: No. of header-bits per packet
I: No. of information-bits per packet
E: Line efficiency
N: No. of transmissions to get a packet accepted.
L: Packet Length = H+I
then the o̲p̲t̲i̲m̲u̲m̲ ̲p̲a̲c̲k̲e̲t̲ ̲s̲i̲z̲e̲ (which maximizes the line efficiency) will be
I…0f…o…0e… H/p (bit)
and the optimum line efficiency equals:
E…0f…o…0e… 1- H p
and the average no. of transmissions of a packet to get it accepted by the receiver will
be:
N 1+L p
for
p l/L (per bit).
For very long messages it is important that they are chopped into packets, which may be retransmitted.
Otherwise it may be very difficult to get them transferred.
The retransmission facility is implemented on the HDLC - level of the TRUNK - connections.
On the TRANS-connection between an SCC and its collocated node, however, no such retransmission
facility is implemented. Therefore packets my be disturbed and discarded.
The situation that one or more packets are missing will be detected by the receiving Packet
Handler.
All packets of the message(-s) in question will be discarded, and the message(-s) will be
retransmitted.
This is done by releasing resources occupied by packets already received, by deletion of
subsequent packets and by returning a N̲A̲C̲K̲ to the sending neighbour.
It is seen that a NACK is a request for retransmission of one or more entire message(-s)
for repair of a transient trunk failure.
3.1.1.5 P̲e̲r̲m̲a̲n̲e̲n̲t̲ ̲T̲r̲u̲n̲k̲ ̲F̲a̲i̲l̲u̲r̲e̲
If a transmission line is broken, or if the power is switched off a modem, then the failure
is so serious that the trunk cannot be used for a shorter or longer time; this error is reported
to both nodes. The trunk state is set to disconnected.…86…W …02… …02… …02… …02… …02… …02…
All messages outbound on that trunk (and not yet acknowledged) must be rerouted.
All messages inbound on the trunk and only partly received (i.e. the first but not the last
packet is received) must have their resources released.
These messages will be rerouted by the sender.
It is seen that there may now exist a mismatch between the packet- and the message numbers
of the two nodes. Therefore when the trunk has been repaired and being re-opened the packet-
and the message counters of the two neighbours must be brought to agree for that trunk.
The trunk states and the transitions between them are shown in the figure overleaf.…86…W
…02… …02… …02… …02… …02… …02…
OPEN
open close
CLOSED
(or CONNECTED)
disconnect
connect disconnect
DISCONNECTED
FIG. 3.1.1.5-1:
THE TRUNK STATES AND THE TRANSITIONS BETWEEN THE STATES…01……86…W …02… …02… …02… …02… …02… …02…
3.1.1.6 N̲o̲d̲e̲ ̲F̲a̲i̲l̲u̲r̲e̲
To detect a failure in a neighbour node a special control message of the very highest priority
level is currently forwarded to each neighbour connected with an open trunk; having transmitted
the message, a t̲i̲m̲e̲r̲ is started. If the timer expires before the message is acknowledged,
it is a retransmitted. If the timer expires after having retransmitted once, the neighbour
is assumed to have failed.
Whatever the node failure is transient or permanent, transmission of message traffic will
be avoided; the data user traffic, however, will continue to flow.
Therefore messages outbound for the failed node will be rerouted. Partly received messages
inbound from the node will be released - later, when the failed node is restarted, they will
be retransmitted.
The SCC is informed abouth the node failure if possible, and new routing tables are generated.
When the former failed node is r̲e̲s̲t̲a̲r̲t̲e̲d̲, the former open trunks are automatically reopened
from that node. As mentioned above old outbound messages (i.e. messages for which the failed
node was responsible) are rerouted and retransmitted.
If the former failed node is s̲t̲a̲r̲t̲e̲d̲ from scratch, the trunks must be opened by the supervisor.
If a "failure" is erroneously detected in a neighbour actually running possible messages
form the "failed" neighbour are acknowledged; otherwise the neighbour will recognize the
present node as failed! The situation may be recovered simply by a CLOSE TRUNK followed by
an OPEN TRUNK command.…86…W …02… …02… …02… …02… …02… …02…
3.1.2 M̲u̲l̲t̲i̲a̲d̲d̲r̲e̲s̲s̲i̲n̲g̲
Messages for m̲u̲l̲t̲i̲p̲l̲e̲ ̲(̲M̲E̲D̲E̲-̲)̲ ̲a̲d̲d̲r̲e̲s̲s̲e̲e̲s̲ (fig. 3.1.2-1) are handled by the network as described
below:
Referring to fig. 3.1.2-2 you will find that a message is equipped with a r̲o̲u̲t̲i̲n̲g̲ ̲m̲a̲s̲k̲ placed
in the binary header. In the routing mask an indication is set for each MEDE, SIP or SCC
which shall be delivered one copy.
The names of the destinations are the letters:
A : MEDE
B : MEDE
E : MEDE
F : MEDE
H : MEDE
K : MEDE
L : MEDE
N : MEDE
P : SCC, collocated N/M "E"
Q : SCC, collocated N/M "K"
S : SIP at N/M "E"
Z : SIP at N/M "K"
As late as possible a copy is made for each trunk, which must transmit the message. Each
copy is equipped with an appropriate routing mask, which is a s̲u̲b̲s̲e̲t̲ of the routing mask
received in the node. All copies are handled according to a commmon action-precedence level.
One copy is given to each destination MEDE, or SCC or SIP, independently of how many copies
are made at the communication centers.…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.1.2-1:
THE NETWORK AND ITS USERS
THE ADDRESSEES ARE MEDE…08…s, SCC…08…s AND SIP…08…s…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.1.2-2:
MULTIADDRESSING, COPYING AND ROUTING.
(The trunks HF1, HL1 and HN1 are thought to be disconnected)…86…W …02… …02… …02… …02… …02… …02…
3.1.3 F̲l̲o̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲
3.1.3.1 R̲o̲u̲t̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲
The network is a m̲e̲s̲s̲a̲g̲e̲ ̲s̲w̲i̲t̲c̲h̲i̲n̲g̲ ̲n̲e̲t̲w̲o̲r̲k̲, so routing is performed on m̲e̲s̲s̲a̲g̲e̲ ̲l̲e̲v̲e̲l̲; this
means that (finally) all packets of a message follow the same route.
The routing is n̲o̲n̲-̲p̲r̲e̲d̲e̲t̲e̲r̲m̲i̲n̲e̲d̲, which means that it is not determined in advance which
route a message not yet put into the network will follow. The decision is taken from n̲o̲d̲e̲
̲t̲o̲ ̲n̲o̲d̲e̲. The advantage by doing so is that the decision is made on the latest local knowledge
about the state of the nodes and the trunks.
The routing algorithm is run by the SCC.
The routing result of the algorithm contains three alternate results per destination despite
the fact that it is run when t̲h̲e̲ ̲t̲o̲p̲o̲l̲o̲g̲y̲ is changed and when t̲h̲e̲ ̲d̲e̲l̲a̲y̲ is changed. The
reason is that it must be possible to perform routing also in the period of time when the
algorithm is executed, i.e. from some changes occur until new Routing Tables are calculated
and distributed.
A complete set of Routing Tables is shown in Fig. 3.1.3.1-1.…86…W …02… …02… …02… …02… …02…
…02…
FIG. 3.1.3.1-1
THE ROUTING TABLE OF EACH NODE…86…W …02… …02… …02… …02… …02… …02…
It must be pointed out that in a period of time where the routing in the individual nodes
is based on different information about the network, o̲s̲c̲i̲l̲l̲a̲t̲i̲o̲n̲s̲ ̲a̲n̲d̲ ̲l̲o̲o̲p̲i̲n̲g̲s̲ ̲o̲f̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲
my occur. The reasons may be:
- two nodes may disagree about the availability of a trunk or a node.
- the information about topology and delay needs some time to spread out through the network,
i.e. the routing tables arrive at different times at different nodes.
The routing algorithm must ensure that when using the same knowledge of the network, then
two nodes agree abouth the optimum route.
The amount of oscillations and loooping of messages in the network will be controlled by
the "O̲r̲b̲i̲t̲ ̲C̲o̲u̲n̲t̲e̲r̲" of each message. The counter is a part of the binary header. When entering
the network it is a preset to 20; it is reduced by one, when passing a node; reaching 0 the
message is transferred to the supervisor of the NODE/MEDE. In this way some small amount
of oscillitions and loopings is tolerated.
Narrative and control messages locked up in a node (because all trunks are cut, or the destination
is not available) are transferred to the supervisor of the NODE/MEDE.
A message retransmitted from a node to its neighbour node 3 times without success is transferred
to the supervisor of the NODE/MEDE.…86…W …02… …02… …02… …02… …02… …02…
In a collocated node control messages for the SIP are put into the SIP-Q, and narrative messages
for the SIP are put into the MDS-Q (see Fig. 3.1.3.1-2)
A data user may be switched from the secondary to the primary route by a control message
from the SCC.
3.1.3.2 T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲
Traffic control means control of the amount of traffic in the network; this is done in two
ways:
- messages from the network to the local MEDE are given a higher priority than relay messages.
Relay messages are given a higher priority than new messages entering the network from
MEDE - to ensure that the network is not overloaded.
- if the length of the Trunk Queue exceeds the threshold, this is reported to the SCC.
This is an indication of congestion in the neighbour at the far end of the trunk.…86…W
…02… …02… …02… …02… …02… …02…
FIG. 3.1.3.1-2:
FLOW OF MESSAGES FOR THE SIP…86…W …02… …02… …02… …02… …02… …02…
3.1.3.3 C̲o̲n̲g̲e̲s̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
Congestion Control is performed by giving certain types of messages higher priority than
others.
6̲ ̲+̲ ̲1̲ ̲p̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲l̲e̲v̲e̲l̲s̲ are handled:
0. super flash S (for control messages:
ACK,NACK, MICK and MACK only)
1. flash Z
2. rush Y
3. immediate O
4. priority P
5. quick M
6. routine R
3.1.4 E̲r̲r̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
3.1.4.1 P̲h̲y̲s̲i̲c̲a̲l̲ ̲L̲e̲v̲e̲l̲
Trunk disconnection, soft trunk failures, and unsuccessful NPDN call-up/close-down are detected
and reported from the LTUX-TRUNK and LTUX-NPDN.
3.1.4.2 L̲i̲n̲k̲ ̲L̲e̲v̲e̲l̲
Frame format errors are detected and corrrected on the Link Level. Cryto Garbling is detected
and reported.
3.1.4.3 P̲a̲c̲k̲e̲t̲ ̲L̲e̲v̲e̲l̲
Errors detected and reported by the Packet Handler are:
Packet Format Error and Missing Packet.
L̲E̲V̲E̲L E̲R̲R̲O̲R̲S̲
5: Node-to-Node Neighbour Node Failure
4: Message Missing message
Phantom message
Hard Trunk Failure
Neighbour Node Failure
Message locked out from destination
Orbit message
Trunk Queue threshold exceeded
3: Packet Packet format error
Missing packet
2: Link Cryto garbling
Frame error
Too many retransmissions
1: Physical Trunk disconnected
Soft trunk failure
Unsuccessful NPDN call-up/close-down
FIG. 3.3-7:
ERRORS AND LEVELS. THE ERRORS ARE GROUPED
ACCORDING TO THE LEVEL WHERE THEY ARE FIRST RECOGNIZED…86…W …02… …02… …02… …02… …02… …02…
3.1.4.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲e̲v̲e̲l̲
Errors detected but not corrrected on the packet level are reported to the message level.
These may be:
- Missing Message.
Too many retransmissions of messages to the next node are reported to the supervisors (Hard
Trunk Failure or Neighbour Node Failure). Duplicated messages are cancelled. Messages may
be locked out from their destination; such messages are transferred to the MEDE supervisor.
Trunk Queue Threshold Alarms and Orbiting Messages are reported to the SCC.
3.1.4.5 N̲o̲d̲e̲-̲t̲o̲-̲N̲o̲d̲e̲ ̲L̲e̲v̲e̲l̲
A node failure is detected and reported from its neighbours.
3.1.4.6 E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
The follwoing error reports are sent to the supervisor of the MEDE:
Report: Trunk failure, hard/soft
Node failure
Unsuccessful NPDN call-up/close-down.
…86…W …02… …02… …02… …02… …02… …02… …02…
The MDS-Q receives narrative messages locked-out, orbiting or being retransmitted too many
times.
The below mentioned error reports are sent to the supervisor of the SCC.
Local Network
Status Report: - Trunk failure
- NPDN assignment
- Trunk Queue Threshold
- Node failure
- Change of Data User Route
- Crypto failure
- Orbiting narrative message
One-hour reports are sent to the supervisor of the SCC containing:
- No. of frames transmitted per trunk
- No. of frames retransmitted per trunk
- Trunk load
- DTG of oldest message per precedence per trunk.
3.1.5 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲
The NSS forwards s̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲i̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ to the SCC each hour:
- No. of frames retransmitted per trunk
- Trunk load: No. of text characters transmitted
- Trunk queue length: No. of messages per precedence
- DTG of oldest message per precedence per trunk.
The information is transmitted by a control message.
3.1.6 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲
Network control is performed from the SCC by distributing control messages to the individual
nodes. It may also be performed locally by the MEDE supervisor.
Network control performed by the SCC covers:
- Routing Tables
- Open/Close Trunk
- Selection of primary Data User route
- Set alarm threshold of retransmission rate
- Set alarm threshold of Trunk Queue length
Local control performed by the MEDE supervisor covers:
- Local updating of Routing Table
- Open/Close trunk
- NPDN call-up/close-down
- Data User Reconfiguration…86…W …02… …02… …02… …02… …02… …02…
3.1.7 S̲t̲a̲r̲t̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
3.1.7.1 R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲y̲
The NSS receives l̲o̲c̲a̲l̲ generated messages and r̲e̲m̲o̲t̲e̲ ̲ generated messages for routing and
transmission.
The local generated messages are those generated by the local MEDE/SCC or by the NSS itself.
They are put into the TRP-Q.
The remote generated messages are those received from the neighbour nodes via the input trunks.
An MTCB is generated, the message is stored on disc, and an ACK is returned to the sender.
The NSS is r̲e̲s̲p̲o̲n̲s̲i̲b̲l̲e̲ for each of the above mentioned messages until it has been put into
an output queue (MDS-Q, CIP-Q, SIP-Q, CTR-Q or PGE-Q) and/or until it has been transmitted
via an output trunk, and an ACK has been received.
"Responsible" means that during a possible recovery situation the NSS must ensure that the
messages are not lost, but correctly reprocessed.
3.1.7.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
By means of checkpoints the book-keeping of messages for which the NSS is responsible are
currently updated.
Local generated messages put into the TRP-Q are p̲o̲s̲i̲t̲i̲v̲e̲l̲y̲ checkpointed by the supplier (fig.
3.1.7.2-1).
Remote generated messages are p̲o̲s̲i̲t̲i̲v̲e̲l̲y̲ checkpointed when written on disc before the ACK
is returned.
Whenever a message for which the NSS is responsible is put into an output queue (MDS-Q, CIP-Q,
SIP-Q, CTR-Q, PGE-Q, TRK-Q) a positive checkpoint is made. For the TRK-Q, however, this
is done by saving the OMB (Outbound Message Buffer) onto the OMF (Outbound Message File or
NSS Checkpoint File) (Ch. 3.4.2.7).
When a message is deleted from a queue (TRP-Q, CTR-Q, TRK-Q) a n̲e̲g̲a̲t̲i̲v̲e̲ checkpoint is made.
For the TRK-Q, however, this is done by saving the OMB onto the OMF.…86…W …02… …02… …02… …02…
…02… …02…
S̲U̲B̲S̲Y̲S̲T̲E̲M̲ ̲ A̲C̲T̲I̲O̲N̲ R̲E̲S̲P̲O̲N̲S̲I̲B̲L̲E̲
B: ACCESS MSG. IN QUEUE AB
B
B: PROCESS MSG
B: PUT MSG. INTO QUEUE BC
B: MAKE A POSITIVE CHECKPOINT FOR C
B: MAKE A NEGATIVE CHECKPOINT FOR B
B: REMOVE MSG. FROM QUEUE AB
C: ACCESS MSG. IN QUEUE BC
C
C: PROCESS MSG.
C: PUT MSG. INTO QUEUE CD
C: MAKE A POSITIVE CHECKPOINT FOR D
C: MAKE A NEGATIVE CHECKPOINT FOR C
C: REMOVE MSG. FROM QUEUE BC
D
FIG. 3.1.7.2-1:
POSITIVE AND NEGATIVE CHECKPOINTS
3.1.7.3 R̲e̲s̲t̲a̲r̲t̲
During a restart the former cold stand-by N/M computer is started, i.e. the subsystems incl.
the NSS are initialized with the common RESTART ̲FLAG set to TRUE.
3.1.7.4 R̲e̲c̲o̲v̲e̲r̲y̲
All queues and MTCB…08…s are regenerated.
The NDF (Nodal Data File) is loaded as left by the failed branch. In this way neither routing
information nor trunk- nor data user status are lost.
The OMB is loaded from the OMF.
All trunks, which were open during the crash, are re-opened.
The OMB is scanned, emptied and each message is put into the TRP ̲Q for rerouting and retransmission.
After recovery normal processing continues and no messages are lost.
3.1.7.5 S̲t̲a̲r̲t̲
The very first initialization of a N/M is called the start. The subsystems incl. the NSS
are loaded, initialized are started with the commom RESTART ̲FLAG set to FALSE.
There are no messages within the subsystems for which they are responsible.
3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The entire network forms a m̲e̲s̲s̲a̲g̲e̲ ̲s̲w̲i̲t̲c̲h̲i̲n̲g̲ ̲s̲y̲s̲t̲e̲m̲, i.e. entire messages are stored and
forwarded in each node. The interface between t̲h̲e̲ ̲u̲s̲e̲r̲s̲ ̲a̲n̲d̲ ̲t̲h̲e̲ ̲n̲e̲t̲w̲o̲r̲k̲ is not X.25, but
some q̲u̲e̲u̲e̲s̲ of messages; the interface b̲e̲t̲w̲e̲e̲n̲ ̲t̲h̲e̲ ̲n̲o̲d̲e̲s̲, however, is very similar to X.25,
cfr. fig. 1.1-1.
The N̲S̲S̲ is surrounded by the processes of the M̲E̲D̲E̲, or a S̲C̲C̲, a possible dummy SCC called
the S̲I̲P̲, the D̲a̲t̲a̲ ̲U̲s̲e̲r̲s̲, the t̲r̲u̲n̲k̲s̲, the T̲I̲M̲E̲R̲-, the P̲U̲R̲G̲E̲-, the C̲H̲E̲C̲K̲P̲O̲I̲N̲T̲ ̲p̲r̲o̲c̲e̲s̲s̲ and the
D̲a̲t̲a̲ ̲B̲a̲s̲e̲s̲.
The interfaces to the MEDE, the SIP and the SCC are input- and output queues. The interfaces
to the Data Users and the trunks are the I/O-system and the TDX-driver. The interface to
the Data Bases is the I/O-system.
Inside the network are flowing c̲o̲n̲t̲r̲o̲l̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲. Besides t̲h̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲t̲r̲a̲f̲f̲i̲c̲, which is controlled
by the NSS, also d̲a̲t̲a̲ ̲t̲r̲a̲f̲f̲i̲c̲ is flowing on the trunks and through the nodes. Except for
some error-reporting, switching from secondary to primary data route, and Data User Reconfiguration,
there is no interface between NSS and the data traffic.
An overview of the entire t̲r̲a̲f̲f̲i̲c̲ through a node is given in fig. 3.2-1.
Fig. 3.2-2 defines the t̲e̲r̲m̲i̲n̲o̲l̲o̲g̲y̲ concerning the message traffic through the NSS.
The Data Bases are detailed described in ch. 3.4.2.…86…W …02… …02… …02… …02…
FIG. 3.2-1:
TRAFFIC THROUGH A NODE
FIG. 3.2-2:
THE MESSAGE TRAFFIC THROUGH THE NSS…86…W …02… …02… …02… …02…
3.2.1 T̲h̲e̲ ̲M̲E̲D̲E̲
The NSS communicates with the MEDE via the NSS input queue (the T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲Q̲u̲e̲u̲e̲) and an output
queue (the M̲D̲S̲ ̲Q̲u̲e̲u̲e̲), and via the common data bases: the P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲(̲P̲B̲D̲)̲,̲ the
H̲i̲s̲t̲o̲r̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲(̲H̲D̲B̲)̲, and the I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲e̲ ̲(̲I̲M̲F̲)̲.
In fact the MDS-Queue consists of 1̲+̲6̲ ̲s̲u̲b̲q̲u̲e̲u̲e̲s̲, one per precedence level: 1 super flash
level (not used) and 6 standard precedence levels. It is used for (narrative and control)
messages destinating this MEDE. The messages themselves are stored on the IMF; a queue-element
consists of a pointer to an MTCB, which points to the message on the disc, fig. 3.2.1-1.
The Transport Queue consists of 3 parts: one part for messages generated at the l̲o̲c̲a̲l̲ MEDE
and a possible collocated SIP, one part for control- and narrative messages in r̲e̲l̲a̲y, and
one part for messages d̲e̲l̲a̲y̲e̲d̲ due to flow control, see ch. 3.4.3.2; each part consists of
1+6 subqueues, one per precedence level. Local messages are stored in the PDB (SPECAT messages)
or the HDB (non-SPECAT messages); a queue element is a pointer to an MTCB.…86…W …02… …02…
…02… …02…
FIG 3.2.1-1
THE INTERFACES BETWEEN
THE MEDE, THE CIP, THE SIP ND THE NSS.…86…W …02… …02… …02… …02…
3.2.2 T̲h̲e̲ ̲S̲I̲P̲
The SCC Interface Process, the SIP, is a dummy SCC in a collocated N/M-computer. It acts
as an SCC during off-line conditions.
The interface is the SIP Queue (or SDQ), which consists of 1+6 subqueues, one per precedence
level, see fig. 3.2.1-1.
3.2.3 T̲h̲e̲ ̲S̲C̲C̲
The interface to the SCC is the CIP Queue and the Transport Queue. Control messages from
the SCC may be Routing Tables or control of Data Users; control messages to the SCC may be
statistics or reports. Narrative messages are messages to or from NICS/TARE. Messages between
the SCC and the collocated node are not encrypted. They are transferred via the red TDX-bus,
and the TRANS-connection.
3.2.4 T̲h̲e̲ ̲T̲r̲u̲n̲k̲s̲
The connection between a pair of nodes in the FIKS network falls in one of the categories:
- TRUNK…08…s
- NPDN…08…s
- TRANS…08…
The trans connection is used between an SCC and its collocated node; the traffic is non-encrypted.…86…W
…02… …02… …02… …02…
All other connections are usually of the category trunk. A disconnected trunk, however,
may be substituted by an NPDN connection. The traffic is encrypted.
The connections are shown on fig. 3.2.4-1
Very often, however, any of the categories will be called a "trunk" for short.
The maximum number is 7 trunks/trans and 1 NPDN radiating from a node.
Each half (or simplex) TRUNK/NPDN/TRANS is identified by:
trunk identification ::=
from node to node trunk serial no.
The trunks are also given consecutive numbers, also called Entry Nos or Incarnation Nos:
0, 1,..., 7.
Trunk Entry No. 0 is used for a possible NPDN connection, see fig. 3.2.4-2.…86…W …02… …02…
…02… …02…
FIG 3.2.4-1
THE CONNECTIONS BETWEEN NODES AND SCC…08…s…86…W …02… …02… …02… …02…
FIG. 3.2.4-2
NUMBERING OF TRUNKS…01……86…W …02… …02… …02… …02…
The NSS communicates packets with the red LTUX CRYPTO and the LTUX TRANS via the AMOS I/O-system,
the red TDX-driver, the red HOST I/F, and the red TDX-bus.
The NSS communicates supervisory information with the LTUX…08… via the AMOS I/O-system, the black
TDX-Driver, the black HOST I/F and the black TDX-bus.
Also initialization information is communicated to the LTUX…08… from the NSS.
The NSS communicates with the LTUX…08… through loglines.
The maximum dato field length of a data packet is 512 bytes, see fig. 3.2.4-3.
Preceding the data field is found an X.25 packet header, a protocol header containing the
trunk-id, an HDLC-header and a CRYPTO-header.
The protocol header on an outbound packet is used by the red LTUX-CRYPTO; on an inbound packet
it is used by the Packet Handler; in both cases for identification of the trunk.…86…W
…02… …02… …02… …02…
FIG. 3.2.4-3
THE SIZE OF A PACKET…86…W …02… …02… …02… …02…
3.2.5. T̲h̲e̲ ̲D̲a̲t̲a̲ ̲U̲s̲e̲r̲s̲
As mentioned previously also the LTUX…08…s of the Data Users are connected to the NSS directly
via the black TDX-bus.
The purpose is switching and error control.
3.2.6 T̲h̲e̲ ̲T̲i̲m̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲
The Timer Process awakes the NSS:
- on the hour for creation of statistics
and hourly report for the SCC…08…s. Identification =
# FFFF.
- at "time out" after having sent the last packet of a message to a neighbour
node. Identification =
Node-to-Node serial No 6+ Precedence 3+ Trk.Inc. No.
The NSS is awoken by returning an answer containing the identification of the call.
3.2.7 T̲h̲e̲ ̲P̲u̲r̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
The Purge Process performs purging of "special handling" messages before final release.
The NSS puts such messages into the Purge Queue after successful transmission to the next
node.…86…W …02… …02… …02… …02…
3.2.8 T̲h̲e̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲
Each time a positive or negative checkpoint is done by the NSS, a KERNEL message is sent
to the Checkpoint Process; when the Queue- and MTCB-information has been saved on disc, an
answer is returned.
The first time a positive checkpoint is made after having created and filled an MTCB, the
Checkpoint Process is also asked to update the MTCB before saving.
3.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.3.1 T̲h̲e̲ ̲M̲o̲d̲u̲l̲e̲s̲ ̲o̲f̲ ̲N̲S̲S̲
The Nodal Switch Subsystem consists of the modules:
- The Packet Handler Module
- The Transport Station Module
- The Monitoring Module
- The Control Module
- The Event Module
- The Starting Module.
see fig. 3.3.1-1
They are all described in details in the chapters
3.3.4 through 3.3.9.…86…W …02… …02… …02… …02…
FIG. 3.3.1-1
THE MODULES,QUEUES AND BUFFERS OF THE NSS…86…W …02… …02… …02… …02… …02…
3.3.2 T̲h̲e̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲
The modules or submodules of the NSS form one or several coroutines:
PACKET HANDLER
Inbound Packet Handler 1+T coroutine(s)
Outbound Packet Handler 1+T coroutine(s)
Packet Input 2 coroutines
Packet Output 2 coroutines
TRANSPORT STATION
Transport Station, inbound 1+T coroutine(s)
Transport Station, outbound 1 coroutine
MONITORING MODULE 1 coroutine
CONTROL MODULE 1 coroutine
EVENT MODULE 1 coroutine
STARTING MODULE 1 coroutine
where 1+T means the No. of trunks, NPDN and trans.
Together with the Coroutine Monitor they all form one process.
The coroutines are synchronized and they exchange information by means of operations which
are waited for at and signalled to semaphores.
An overview of the Coroutine Monitor Procedures used is given on the next pages.
W̲A̲I̲T̲-̲C̲H̲A̲I̲N̲E̲D̲
PROCEDURE WAITCH (SEMAPHORE, OPERATION)
This procedure fetches an operation from a semaphore. In case an operation is ready when
the procedure is called, the operation is simply handed to the calling coroutine.
In case no operation is ready at call time, the calling coroutine is delayed until an operation
arrives for it.
This is a waiting point procedure.
S̲I̲G̲N̲A̲L̲-̲C̲H̲A̲I̲N̲E̲D̲
PROCEDURE SIGNALCH (SEMAPHORE, OPERATION)
This procedure delivers an operation at a chained semaphore. In case a coroutine is already
waiting at the semaphore, the operation is handed to this coroutine, which is then put into
the ready queue (for later activation).
In case no coroutine waits at the semaphore, the operation is linked to it, waiting to be
fetched by wait-chained.
W̲A̲I̲T̲-̲O̲P̲E̲R̲A̲T̲I̲O̲N̲S̲
PROCEDURE WTOPS
(MASK; FA,BLE,OP.REF., FD/TYPE,IDENT,ADDR)
This procedure delays the calling coroutine until the ready queue is empty and until an external
event arrives to the process, e.g. I/O operation complete, answer, or signal.
This is a waiting point procedure.
Note that only one coroutine may wait for an event external to the process at a time.…86…W
…02… …02… …02… …02… …02…
P̲A̲S̲S̲
PROCEDURE PASS
This procedure moves the coroutine to the end of the ready queue.
The procedure should be used with care, because the ready queue is not emptied.
D̲E̲L̲A̲Y̲
PROCEDURE DELAY
This procedure delays the calling coroutine until another coroutine waiting for an external
event has been made active.
This is a waiting point procedure.
Several coroutines may be delayed at a time.
3.3.3 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
During assembly the coroutines of the NSS are linked together as indicated by the arrow
on the figure overleaf.
When started or restarted the coroutines are initialized in the order of linkage, i.e. as
indicated by the arrow.
A detailed listing of what is happening during a start and a restart is listed on the subsequent
pages.…86…W …02… …02… …02… …02… …02…
INITCH:
STARTING MODULE:
EVENT MODULE:
CONTROL @MODULE:
MONITORING MODULE:
TRANSPORT STATION, OUT:
TRANSPORT STATION, IN:
PACKET HANDLER, OUT:
PACKET HANDLER, OUT:
PACKET HANDLER, IN:
FIG. 3.3.3-1
THE LINDING AND INITIALIZATION OF THE NSS COROUTINES…86…W …02… …02… …02… …02… …02…
3.3.3.1 N̲o̲d̲e̲ ̲S̲t̲a̲r̲t̲
M̲o̲d̲u̲l̲e̲ F̲u̲n̲c̲t̲i̲o̲n̲
SM - OPEN NDF
- READ SEGMENT # 1 OF NDF INTO ND.
- OPEN JACKFILE
- READ JACKFILE INTO JACKTABLE
- OPEN IMF
- OPEN CPF
- INIT ̲MTCB incl. OPEN HDB
OPEN IMF
OPEN PDB ̲DIRECTORY
- INITIALIZE COROUTINE ̲MONITOR
- RESET "OUTBOUND MESSAGE BUFFER"
EM - empty
CM - SIGNAL "NODE ̲START" ̲OP TO MM
MM - START 1H TIMER
- START 30 S TIMER
- INITILIZE STATISTICS, HOURLY ̲REPORT ETC.
- READ "NODE START" ̲OP FROM CM.
- CONFIGURE LTUX…08… FOR START
TSO - WRITE "OUTBOUND MESSAGE BUFFER" INTO CPF.
TSI - empty
PH - empty
SM - STOP…86…W …02… …02… …02… …02… …02…
3.3.3.2 N̲o̲d̲e̲ ̲R̲e̲s̲t̲a̲r̲t̲
M̲o̲d̲u̲l̲e̲ F̲u̲n̲c̲t̲i̲o̲n̲
SM - OPEN NDF
- READ SEGMENT #0 OF NDF INTO ND
- OPEN JACKFILE
- READ JACKFILE INTO JACKTABLE
- OPEN IMF
- OPEN CPF
- READ CPF INTO "OUTBOUND MESSAGE BUFFER"
- INIT ̲MTCB incl. OPEN HDB
OPEN IMF
OPEN PDB ̲DIRECTORY
- INITIALIZE COROUTINE MONITOR
EM - empty
CM - SIGNAL "NODE-RESTART" ̲OP TO MM
- SIGNAL "RE-OPEN TRUNKS" ̲OP TO MM
MM - START 1H TIMER
- START 30 s TIMER
- INITIALIZE STATISTICS, HOURLY-REPORT etc.
- READ "NODE RE-START" ̲OP FROM CM.
- CONFIGURE LTUX…08… FOR RESTART
- READ "RE-OPEN TRUNKS" ̲OP FROM CM.
- REOPEN TRUNKS
TSO - empty
TSI - empty
PH - X.25 - RESTART OF TRUNKS
SM - STOP
MM - ASK TSO TO RE-ROUTE MSGS.
TSO - MOVE MSGS FROM "OUTBOUND MESSAGE BUFFER" INTO TRP-Q.
3.3.4 T̲h̲e̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲
3.3.4.1 G̲e̲n̲e̲r̲a̲l̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
3.3.4.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
T̲h̲e̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲ performs the X̲.̲2̲5̲ ̲l̲e̲v̲e̲l̲ ̲3̲ packet handling.
The connection for packets to the trunks is via the ̲I̲/̲O̲-̲s̲y̲s̲t̲e̲m̲,̲ the r̲e̲d̲ ̲T̲D̲X̲-̲d̲r̲i̲v̲e̲r̲ and the
r̲e̲d̲ ̲c̲r̲y̲p̲t̲o̲ ̲L̲T̲U̲X̲ common to all trunks. The interfae to the I/O-system are the C̲y̲c̲l̲i̲c̲ ̲I̲n̲p̲u̲t̲
̲B̲u̲f̲f̲e̲r̲ and the P̲o̲o̲l̲ ̲o̲f̲ ̲P̲a̲c̲k̲e̲t̲ ̲B̲u̲f̲f̲e̲r̲s̲
Input packets are transferred to the T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲.̲ Output packets for the Packet
Handler are stored in the Trunk Queue by the Transport Station Module.
The Packet Handler is divided into:
- the Inbound Packet Submodule
- the Outbound Packet Submodule
- the Input Submodule
- the Output Submodule
The red crypto LTUX mentioned above and a possible LTUX TRANS is initialized by the Monitoring
Module.
3.3.4.1.2 P̲r̲o̲t̲o̲c̲o̲l̲s̲
3.3.4.1.2.1 T̲h̲e̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The below mentioned I̲/̲O̲-̲c̲o̲m̲m̲a̲n̲d̲s̲ are used:
- init-read-bytes
- init-append-bytes.
3.3.4.1.2.2 T̲h̲e̲ ̲L̲T̲U̲X̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The LTUX Protocol is the agreement between the NSS (t̲h̲e̲ ̲m̲a̲s̲t̲e̲r̲) and the red Crypto LTUX and
a possible LTUX TRANS (t̲h̲e̲ ̲s̲l̲a̲v̲e̲s̲) on exchange of packets.
T̲h̲e̲ ̲p̲a̲c̲k̲e̲t̲ ̲f̲o̲r̲m̲a̲t̲ is described in chapter 3.3.4.1.3
The Monitoring Module will create the below mentioned log-lines for each slave:
- sub-device # 0:Connection
- sub-device # 2:Device control, -status and-error
- sub-device # 3:Packet transfer
A p̲a̲c̲k̲e̲t̲ ̲i̲s̲ ̲o̲u̲t̲p̲u̲t̲ to the slave only if the red Crypto LTUX/LTUX TRANS has reported: "o̲u̲t̲p̲u̲t̲
̲t̲r̲u̲n̲k̲ ̲n̲o̲n̲-̲b̲u̲s̲y̲" (which means: the device is ready to receive the next output packet).…86…W
…02… …02… …02… …02…
L̲T̲U̲X̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲
Status Packet present node
(from: LTUX neighbour node trunk id
to : NSS ) trunk serial #
packet header
output trunk busy/non-busy
X̲.̲2̲5̲ ̲P̲A̲C̲K̲E̲T̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲
Data Packet from node
to node trunk id
trunk serial #
packet header
data field (0-512 bytes)
Control Packet from node
to node trunk id
trunk serial #
packet header
FIG. 3.3.4.1.2.2-1.0:
FORMAT OF PACKETS…86…W …02… …02… …02… …02…
Note that after having executed the "init-append-bytes" statement the red Crypto LTUX (if
equipped with the sufficient number of buffers) will immediately be ready for execution of
another "init-append-bytes" statement.
It must be possible for the crypto LTUX to distinguish LTUX Protocol Packets from X.25 Packets.
Therefore the length of the LTUX Protocol Packets is less than 6 bytes while the length
of the X.25 Packets is guaranteed to be 6 bytes or more.
3.3.4.1.2.3 T̲h̲e̲ ̲X̲.̲2̲5̲ ̲L̲e̲v̲e̲l̲ ̲3̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The software submodules implements most of the facilities described in t̲h̲e̲ ̲C̲C̲I̲T̲T̲ ̲X̲.̲2̲5̲ ̲l̲e̲v̲e̲l̲
̲3̲ recommendation. The most significant difference is the absence of t̲h̲e̲ ̲R̲E̲J̲E̲C̲T̲/̲r̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
facility. This facility is not necessary because the Node-to-Node control on message level
is implemented according to the message switching philosophy.
3.3.4.1.3 P̲a̲c̲k̲e̲t̲ ̲F̲o̲r̲m̲a̲t̲
The format of a packet is:
- trunk-id
- packet header
- status- or control- or data information.…86…W …02… …02… …02… …02…
Level 3 permits multiplexing of several logical channels on a single transmission line (trunk)
and performs error- and flow control on the data packet transmission on each individual logical
channel.
X̲.̲2̲5̲ ̲O̲p̲t̲i̲o̲n̲s̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲e̲d̲ ̲i̲n̲ ̲F̲I̲K̲S̲
Level 3 distinguishes between 2 types of packets, data packets and control packets:
a) Data Packets:
7 6 5 4 3 2 1 0
0 0 0 1 0 0 0 0 Byte No. 3
Logical ch. No.
(Precedence level) Byte No. 4 Packet Header
P (R) M P(S) 0 Byte No. 5
Data Field
0-512 Bytes
The Data Field Maximum Length is a system parameter, and must be a power of 2.
In FIKS a data field maximum length of 512 bytes have been selected.
A window size of 3 is used. This parameter may be set to any value within the interval:
1 window size 7.…86…W …02… …02… …02… …02…
b) Control Packets
7 6 5 4 3 2 1 0
0 0 0 1 0 0 0 0 Byte No. 3
Logical ch. No
if applicable Byte No. 4 "Packet Header"
Command 1 Byte No.5
The control packets used by NSS are:
RR packets (Receive Ready)
RESTART packets
RESTOP packets
RESET packets (Reset of one logical channel)
X̲.̲2̲5̲ ̲O̲p̲t̲i̲o̲n̲s̲ ̲n̲o̲t̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲e̲d̲ ̲i̲n̲ ̲F̲I̲K̲S̲
REJECT packets (request for retransmission of a number of packets).
Control packets concerning establishment and
disconnection of virtual circuits via a
genuine X.25 network.
Interrupt
X̲.̲2̲5̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲E̲x̲t̲e̲n̲s̲i̲o̲n̲s̲ ̲f̲o̲r̲ ̲F̲I̲K̲S̲
a) A trunk identification field has been added to the X.25 packets to support the communication
with LTUX devices and crypto equipment.
7 6 5 4 3 2 1 0
FROM NODE Byte No. 0
TO NODE Byte No. 1
TRUNK SERIAL # Byte No. 2
Packet Header
b) The logical channels are given priority according to precedence level.
The X.25 packets are grouped into X̲.̲2̲5̲ ̲D̲a̲t̲a̲ ̲P̲a̲c̲k̲e̲t̲s̲ and X̲.̲2̲5̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲a̲c̲k̲e̲t̲s̲.̲
The purpose of transmitting the trunk ident is to save memory space: By doing so, only one
log-line common to all trunks must be created instead of one log-line per trunk requiring
as many input buffers.
The h̲e̲a̲d̲e̲r̲ of X.25 packets consists of 3 octets. The data qualifier is permanently equal
to zero. The logical channel group No. is equal to zero; logical channel No. is equal to
the precedence level of the message. The packet sequence numbers cycle through the range
of 0 to 7.
Regarding packets input from a particular trunk, a new message begins if the previous packet
was:
- the last one (the More Data bit was not set)
or
- of another (higher) precedence level.
So packets of up to 7̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲ ̲m̲a̲y̲ ̲b̲e̲ ̲m̲i̲x̲e̲d̲ on a trunk.…86…W …02… …02… …02… …02…
For each logical channel i.e. for each precedence level within a trunk the Packet Handler
operates two counters V̲(̲S̲)̲ ̲a̲n̲d̲ ̲V̲(̲R̲)̲:
input: if packet received without error and ready to receive one more packet
then V(R):= (V(R)+1) mod 8;
if prev P(R) P(R) then prev P(R) := P(R)
output: P(S) := V(S);
P(R) := V(R);
if V(S) (prev P(R) + W) mod 8 (comment: receiver ready)
then V(S):= (V(S) +1) mod 8;
3.3.4.1.4 S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲ ̲b̲e̲t̲w̲e̲e̲n̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲s̲
The s̲e̲m̲a̲p̲h̲o̲r̲e̲s̲ are shown in fig. 3.3.4.1.4-1.0.
FIG. 3.3.4.1.4-1.0
FIG. 3.3.4.1.4-1.0
SEMAPHORES AND COMMON VARIABLES…86…W …02… …02… …02… …02… …02…
3.3.4.1.5 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲,̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
No special i̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ is performed.
After a r̲e̲s̲t̲a̲r̲t̲ the logical channels of all open trunks will be reset by "restart-trunk"
-operations sent from the Monitoring Module, so they will remain open.
The Packet Handler contains no c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ since checkpointing is performed on the message
level.
3.3.4.2 I̲n̲b̲o̲u̲n̲d̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
3.3.4.2.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
The packets are r̲e̲c̲e̲i̲v̲e̲d̲ from the Packet-Input submodule in a packet buffer pointed out from
a p̲a̲c̲k̲e̲t̲ ̲p̲o̲i̲n̲t̲e̲r̲ in the Cyclic Input Buffer according to the logical channel (precedence
per trunk).
The packet pointer consists of 3 fields:
- the starting address of the packet
- the length of the packet
- the more data bit
The packet sequence number P(S) is c̲h̲e̲c̲k̲e̲d̲; for a packet correctly received the id and header
is removed, and the packet pointer is t̲r̲a̲n̲s̲f̲e̲r̲r̲e̲d̲ to the Transport Station.
When the packet pointer is released by the Transport Station, the packet may be a̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲d̲,
i.e. V(R) := (V(R) +1) mod 8.
Missing packets are signalled to the Transport Station causing message retransmission.
3.3.4.2.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
State: Packet Input Signal "Packet Ready"
Semaphore: PHISEM (Trunk)
Op(5,4) : Sender (Packet Handler/Packet Input)
- (7,6) : 0,Packet Ready
- (9,8) : Packet Start Address
-(11,10): Packet Size (bytes)
State: TS-IN Acknowledges Packet Received
Semaphore: PHISEM (Trunk)
Op (5,4) : Sender (Transport Station)
- (7,6) : 0, Packet Received
- (9,8) : 0, Precedence
- (11,10): 0, 0…86…W …02… …02… …02… …02…
FIG. 3.3.4.2.3-1.0
INBOUND PACKET HANDLER…86…W …02… …02… …02… …02…
FIG: 3.3.4.2.3-1.1…86…W …02… …02… …02… …02…
FIG: 3.3.4.2.3-1.2…86…W …02… …02… …02… …02…
FIG: 3.3.4.2.3-1.3…86…W …02… …02… …02… …02…
FIG: 3.3.4.2.3-1.4
PROCEDURE SKPPCK…86…W …02… …02… …02… …02…
3.3.4.2.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
In fig. 3.3.4.2.3 is shown the flowchart of the inbound packet handling per trunk, in other
words one incaration of the coroutine per trunk (leased as well as NPDN) is running.
When a new packet is signalled from the Input Coroutine for that trunk, the logical channel
no. and the more data bit is fetched from the packet header. A packet pointer is reserved
for the logical channel in question, and the packet starting address, the packet length,
and the more data bit are copied into the buffer; it is noticed that a free packet pointer
will be available due to flow control.
The packet is checked, and for a data packet also P(S) and P(R) are checked, the header is
removed, and the checked packet is signalled to the Transport Station Module.
When a packet has been received by the Transport Station, a signal is returned, and the packet
buffer and the packet pointer are released. V(R) for that logical channel is increased by
1 (mod 8). V (R) is equal to the highest P(S) it is able to receive +1 - w.
3.3.4.2.4 S̲i̲z̲e̲
The size of the code is 430 instructions.
The necessary data area occupies approximately
50 No. of trunks words.…86…W …02… …02… …02… …02…
3.3.4.2.5 T̲i̲m̲i̲n̲g̲
About 200 instructions are executed for processing a packet of one inbound message, corresponding
to a cpu-time of 0.44 ms.
3.3.4.3 O̲u̲t̲b̲o̲u̲n̲d̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
3.3.4.3.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
Packets for a trunk are r̲e̲c̲e̲i̲v̲e̲d̲ from the Trunk Queue according to precedence level.
A queue element is an operation as shown in fig. 3.4.3.7-2.
The ACK/NACK operation contains the ACK/NACK message itself.
For other message types the operation is a pointer to the packet on the disc.
The routing mask may be different from the mask input due to copying. If the More Data bit
is equal to zero, the packet is the last one of a message; so within a precedence queue a
packet following one having the More Data bit equal to zero, will be the first one of a message.
When the neighbour node is ready, the packet of the highest precedence level is waited for,
and a packet buffer is reserved from the pool.…86…W …02… …02… …02… …02…
F̲o̲r̲ ̲t̲h̲e̲ ̲f̲i̲r̲s̲t̲ ̲p̲a̲c̲k̲e̲t̲ ̲o̲f̲ ̲a̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲t̲h̲e̲ ̲r̲o̲u̲t̲i̲n̲g̲ ̲m̲a̲s̲k̲,̲ ̲t̲h̲e̲ ̲s̲e̲r̲i̲a̲l̲ ̲n̲o̲.̲,̲ ̲a̲n̲d̲ ̲t̲h̲e̲ ̲o̲r̲b̲i̲t̲ ̲c̲o̲u̲n̲t̲e̲r̲
̲a̲r̲e̲ ̲c̲o̲p̲i̲e̲d̲ ̲i̲n̲t̲o̲ ̲t̲h̲e̲ ̲b̲i̲n̲a̲r̲y̲ ̲h̲e̲a̲d̲e̲r̲, when the packet has been read from disc into the reserved
buffer.
A p̲a̲c̲k̲e̲t̲ ̲h̲e̲a̲d̲e̲r̲ ̲i̲s̲ ̲g̲e̲n̲e̲r̲a̲t̲e̲d̲ containing P(S), P(R) and M. V(S) is increased by 1 : V(S):=
(V(S)+1) mod 8.
When removing a queue element from the Trunk Queue, the queue length is compared to the lower
threshold for the precedence in question; if lower and a threshold alarm has been reported
(by the Transport Station), the alarm is cancelled. The messages removed from the Trunk
Queue are counted for the Monitoring Module.
The packet is t̲r̲a̲n̲s̲f̲e̲r̲r̲e̲d̲ to the Packet-I/O submodule by signalling a short operation to
semaphore POSEM (either LTUX CRYPTO RED or TRANS incarnation).
