top - download
⟦6e940de1a⟧ Wang Wps File
Length: 54841 (0xd639)
Types: Wang Wps File
Notes: FIX/1000/PSP/038
Names: »5198A «
Derivation
└─⟦e48583e73⟧ Bits:30006141 8" Wang WCS floppy, CR 0514A
└─ ⟦this⟧ »5198A «
WangText
6…00……00……00……00……13……0a……00……00……13……0b……13……0f……13…
…13……07……12……0d……12……02……12……06……11……0c……11……0f……11……06……10……0b……10……02……10……07……0f……0a……0f……0c……0f……01……0f……07……0e……0c……0e……00……86…1 …02… …02… …02…
…0f… 5198A/aml…02…FIX/1000/PSP/0038
…02…JL/840726…02……02…
SYSTEM SPECIFICATION
…02……02…FK 7809…0e…
4.1.2 N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
4.1.2.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The main tasks of the Nodal Switch Subsystem (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 NSS is running in each node and each SCC forming
a message switching network, see Figure 4.1.2.1-1.
4.1.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲i̲e̲s̲
4.1.2.2.1 O̲v̲e̲r̲v̲i̲e̲w̲
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 of messages with the local MEDE and
a possibly collocated SCC.
b. MULTIADDRESSING:
- Copying of messages for multiple MEDE-addresses.
c. TRAFFIC CONTROL:
- Routing Control: Routing of messages by
means of routing tables.
Switching from secondary
to primary route of data
users.
- Congestion Control: To give higher priority
to relay messages than
to messages entering the
network, and higher priority
to incoming messages than
to relay messages.
Queue administration.
- Priority Control: The internal queues are
handled by precendence
level.
d. ERROR CONTROL:
Error detection on all protocol levels:
- Physical Level
- Link Level
- Packet Level
- Mesage Level
- Node-to-Node Level
and
- 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.
4.1.2.2.2 T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲B̲e̲t̲w̲e̲e̲n̲ ̲N̲o̲d̲e̲s̲
4.1.2.2.2.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 error free 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
failure (section 4.1.2.2.2.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 4.1.2.2.2.4).
4.1.2.2.2.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.
4.1.2.2.2.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.
4.1.2.2.2.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.
4.1.2.2.2.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…1 …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 Figure 4.1.2.2.2.5-1.
4.1.2.2.2.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 from a node 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 retransmitted. If the timer
expires after having retransmitted once, the neighbour
is supposed to be 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 about 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 from 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…1 …02… …02… …02… …02…
4.1.2.2.3 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̲ (Figure 4.1.2.2.3-1)
are handled by the network as described below:
Referring to Figure 4.1.2.2.3-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 will be made
at the communication centers.…86…1 …02… …02… …02… …02…
4.1.2.2.4 T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.1.2.2.4.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 Figure
4.1.2.2.4.1-1.
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̲ may 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
about 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 because 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.
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 Figure 4.1.2.2.4.1-2).
A data user may be switched from the secondary to the
primary route by a control message from the SCC.
4.1.2.2.4.2 C̲o̲n̲g̲e̲s̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲
Congestion 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 the 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…1 …02… …02… …02… …02…
4.1.2.2.4.3 P̲r̲i̲o̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲
Priority 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
4.1.2.2.5 T̲h̲e̲ ̲N̲S̲S̲ ̲i̲n̲ ̲t̲h̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲e̲n̲t̲e̲r̲s̲
Each System Control Center (i.e. SCC P and Q) has the
NSS installed communicating with the NSS in the collocated
node.
The small differences between the NSS in the SCC's
and the NSS in the other nodes are explained below:
The traffic transmitted between an SCC and the collocated
node is non-encrypted; therefore, there are no LTUX-CRYPTO's,
and the Packet Handler does not manage a log line for
encrypted data.
There are n̲o̲ ̲D̲a̲t̲a̲ ̲U̲s̲e̲r̲s̲ and consequently no Jack File.
There is no LTUX polling.
The TRANS-connection between the SCC and the collocated
node c̲a̲n̲n̲o̲t̲ be replaced by an N̲P̲D̲N̲ ̲c̲o̲n̲n̲e̲c̲t̲i̲o̲n̲.
The queue corresponding to the MDS-Q is called the
C̲I̲P̲-̲Q̲.
N̲o̲d̲e̲ ̲R̲e̲s̲t̲a̲r̲t̲ ̲w̲i̲l̲l̲ ̲n̲o̲t̲ ̲b̲e̲ ̲p̲e̲r̲f̲o̲r̲m̲e̲d̲. Therefore, there
are no checkpoints and the Outbound Message Buffer
is not saved.
C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ similar to those generated at other
nodes for the MEDE Supervisors are n̲o̲t̲ generated on
the SCC's.
4.1.2.3 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
4.1.2.3.1 O̲v̲e̲r̲v̲i̲e̲w̲
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 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̲ is very similar to X.75, cfr. Figure 4.1.2.1-1.
The N̲S̲S̲ is surrounded by the processes of the M̲E̲D̲E̲,
or an 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, see Figure 4.1.2.3.1-1.
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.
I̲n̲s̲i̲d̲e̲ ̲t̲h̲e̲ ̲n̲e̲t̲w̲o̲r̲k̲ ̲a̲r̲e̲ ̲f̲l̲o̲w̲i̲n̲g̲ ̲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
the NSS and the data traffic.
An overview of the entire t̲r̲a̲f̲f̲i̲c̲ through a node is
given in Figure 4.1.2.3.1-2.
Figure 4.1.2.3.1-3 defines the t̲e̲r̲m̲i̲n̲o̲l̲o̲g̲y̲ concerning
the message traffic through the NSS.
4.1.2.3.2 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.
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 in Figure 4.1.2.3.2-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 Figure 4.1.2.3.2-2.
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 data field length of a data packet is 512
bytes, see Figure 4.1.2.3.2-3.
Preceding the data field is found an X.75 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…1 …02… …02… …02… …02…
4.1.2.3.3 N̲P̲D̲N̲ ̲C̲a̲l̲l̲-̲u̲p̲ ̲a̲n̲d̲ ̲C̲l̲o̲s̲e̲-̲d̲o̲w̲n̲
A disconnected trunk may be replaced by an NPDN-connection.
Each of the 8 nodes has its own two-digit call number,
so a node c̲a̲n̲n̲o̲t̲ be involved in more than one NPDN
call; therefore, at a given instant a maximum of 4
NPDN connections may be established.
A connection may be dialed from any of the two MEDE's.
As shown in Figure 4.1.2.3.3-1 the control-message
from the MEDE is received by the Control Module. After
a check the call is signalled to the Monitoring Module,
which activates the LTUX-NPDN. Having established
the connection the LTUX at each end informs the Monitoring
Module, which returns a control message to the MEDE.
The state is changed from disconnected to closed.
The connection is closed down in an analogous way,
see Figure 4.1.2.3.3-2.
Being called-up the NPDN connection may be opened and
closed like an ordinary trunk.
Meanwhile, the original trunk may be connected, and
its state will then change to closed. However, it
cannot be opened until the NPDN connection has been
closed down.
4.1.2.4 T̲h̲e̲ ̲M̲o̲d̲u̲l̲e̲s̲
4.1.2.4.1 O̲v̲e̲r̲v̲i̲e̲w̲
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 Figure 4.1.2.4.1-1.
They are all described in details in the chapters
4.1.2.4.4 through 4.1.2.4.9.…86…1 …02… …02… …02… …02…
4.1.2.4.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 given 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 semaphore.
In case a coroutine is already waiting at the semaphore,
the operation is given 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…1 …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.
4.1.2.4.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 in Figure 4.1.2.4.3-1.
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…1
…02… …02… …02… …02…
4.1.2.4.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…1 …02… …02… …02… …02…
…02…
4.1.2.4.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.75 - RESTART OF TRUNKS
SM - STOP
MM - ASK TSO TO RE-ROUTE MSGS.
TSO - MOVE MSGS FROM "OUTBOUND MESSAGE BUFFER"
INTO TRP-Q.
4.1.2.4.4 T̲h̲e̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲
4.1.2.4.4.1 G̲e̲n̲e̲r̲a̲l̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.1.2.4.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̲.̲7̲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 interface 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.
4.1.2.4.4.1.2 P̲r̲o̲t̲o̲c̲o̲l̲s̲
4.1.2.4.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.
4.1.2.4.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.
The Monitoring Module will create the below mentioned
log-lines for each slave:
- sub-device # 0:Initialization
- 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).
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.75 Packets. Therefore
the length of the LTUX Protocol Packets is less than
6 bytes while the length of the X.75 Packets is guaranteed
to be 6 bytes or more.
4.1.2.4.4.1.2.3 T̲h̲e̲ ̲X̲.̲7̲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̲.̲7̲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.
4.1.2.4.4.2 I̲n̲b̲o̲u̲n̲d̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.1.2.4.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 by 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 is returned to the sender.
Missing packets are signalled to the Transport Station
causing message retransmission.
4.1.2.4.4.3 O̲u̲t̲b̲o̲u̲n̲d̲ ̲P̲a̲c̲k̲e̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Packets for a trunk are r̲e̲c̲e̲i̲v̲e̲d̲ from the Trunk Queue
according to precedence level.
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 multi address-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.
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̲u̲m̲b̲e̲r̲,̲ ̲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 on behalf of the Monitoring
Module.
4.1.2.4.4.4 P̲a̲c̲k̲e̲t̲ ̲-̲ ̲I̲/̲O̲
The Packet-I/O communicates with the red TDX-bus (packets
to and from the trunks) via t̲h̲e̲ ̲A̲M̲O̲S̲ ̲I̲/̲O̲-̲s̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲
̲t̲h̲e̲ ̲T̲D̲X̲-̲d̲r̲i̲v̲e̲r̲.
For all trunks (leased as well as NPDN) there is a
common input coroutine, a common output coroutine and
a common data log-line. This log-line is also used
for input of trunk status: Busy/non-busy.
The maximum number of trunks is 7̲ ̲l̲e̲a̲s̲e̲d̲ ̲t̲r̲u̲n̲k̲s̲ and
1̲ ̲N̲P̲D̲N̲ ̲t̲r̲u̲n̲k̲;̲ the latter will temporarily be called
up for substitution of a leased trunk.
A possible TRANS connection has its own input- and
output coroutines and its own data log line.
When the packet has been input, the packet format is
checked; a possible catastrophic failure results in
a termination of the NSS process. The packet starting
address and the packet length are reported to the Inbound
Packet Handling Coroutine for the trunk.
The trunk status (busy, non-busy) is input via the
log-line. The non-busy status is signalled to the proper
Outbound Packet Handling Coroutine.
4.1.2.4.5 T̲h̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
4.1.2.4.5.1 G̲e̲n̲e̲r̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.1.2.4.5.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
Packets received from the Packet Handler are assembled
into entire messages, and the node-to-node message
control and the orbit control are performed.
Messages for the node itself are sent to the Control
Module, messages for the MEDE or SIP are sent to the
MDS, and transit messages are put into the Transport
Queue (Inbound Routing).
The messages are routed (Outbound Routing), and multi-address
messages are copied if necessary. Congestion control
is performed by examining the Trunk Queue length.
Finally outbound packets are disassembled into packets.
The Transport Station is divided into TS-IN (one coroutine
per trunk) for inbound message transport, and TS-OUT
(one coroutine common to all trunks) for outbound message
transport.
4.1.2.4.5.1.2 P̲r̲o̲t̲o̲c̲o̲l̲
According to the message switching philosophy the transport
of an e̲n̲t̲i̲r̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲i̲s̲ ̲c̲o̲n̲t̲r̲o̲l̲l̲e̲d̲ ̲f̲r̲o̲m̲ ̲n̲o̲d̲e̲-̲t̲o̲-̲n̲o̲d̲e̲.
The messages transmitted from one node to another are
n̲u̲m̲b̲e̲r̲e̲d̲ ̲i̲n̲ ̲s̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲o̲r̲d̲e̲r̲ by the sending node.
The receiving node checks that the messages are r̲e̲c̲e̲i̲v̲e̲d̲
̲s̲t̲r̲i̲c̲t̲l̲y̲ ̲i̲n̲ ̲t̲h̲a̲t̲ ̲s̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲o̲r̲d̲e̲r̲.
Regarding multiple trunks and precedence levels it
is seen that t̲h̲e̲ ̲s̲e̲r̲i̲a̲l̲ ̲n̲u̲m̲b̲e̲r̲i̲n̲g̲ ̲m̲u̲s̲t̲ ̲b̲e̲ ̲p̲e̲r̲f̲o̲r̲m̲e̲d̲
̲p̲e̲r̲ ̲t̲r̲u̲n̲k̲ ̲p̲e̲r̲ ̲p̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲l̲e̲v̲e̲l̲; only in this case the
proper order is guaranteed under not-erroneous circumstances.
Consequently it is d̲e̲t̲e̲r̲m̲i̲n̲e̲d̲ ̲b̲y̲ ̲t̲h̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲i̲o̲n̲
̲w̲h̲i̲c̲h̲ ̲t̲r̲u̲n̲k̲ ̲s̲h̲o̲u̲l̲d̲ ̲b̲e̲ ̲u̲s̲e̲d̲ ̲b̲y̲ ̲a̲ ̲m̲e̲s̲s̲a̲g̲e̲ to a neighbour
node.
Immediately after transmission (#0) of a message the
sending node starts a t̲i̲m̲e̲r̲. (In fact this is not done
by the Transport Station, but by the Packet Handler
Module transmitting the last packet).
For each message correctly recieved an A̲C̲K̲ with the
serial no. is returned. Messages received twice (duplet
due to restart) are cancelled; however, they are acknowledged,
see Figure 4.1.2.4.5.1.2-1.
If a message is incorrectly received (packets are missing,
or even entire messages are missing; the message number
is said to be out-of-sequence), a N̲A̲C̲K̲ with the wanted
serial No. is returned.
If the sender does not receive an ACK within a limited
time (which means the receipt of a N̲A̲C̲K̲ ̲o̲r̲ ̲t̲i̲m̲e̲-out),
the message is r̲e̲t̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ up to a maximum of 3 times
(transmission # 1,2,3).
It is emphasized that message control is performed
on each individual copy of a multiaddress message.
A message retransmitted 3 times without being acknowledged
is transferred to the local MEDE-supervisor (if the
neighbour is the destination) or rerouted (if the neigbour
is not the destination). A node failure (after time-outs)
or a hard trunk failure (after NACK…08…s) is reported to
the Monitoring Module.
When a trunk or a node becomes available after a failure
or a restart, the transmission may be restarted after
the trunk has been opened.
4.1.2.4.5.1.3 T̲y̲p̲e̲s̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
As seen from the NSS the types of messages mentioned
below exist:
- narrative messages
- control messages.
The control messages consist of:
- ACK…08…s and NACK…08…s
- MICK…08…s and MACK…08…s
- messages interchanged between the NSS…08…, the
SCC…08…s and the MEDE…08…s.
The ACK…08…s and NACK…08…s have been described in the previous
chapter 4.1.2.4.5.1.2.
The MICK…08…s and MACK…08…s are used for supervision of neighbour
nodes, see section 4.1.2.4.6.4.
The control messages for the NSS are messages for control
of the network and the data users, see section 4.1.2.4.7.2.
The control messages for the SCC and the local MEDE
are statistics, reports, and confirmations, see section
4.1.2.4.6.2.
4.1.2.4.5.2 I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
T̲h̲e̲ ̲i̲n̲b̲o̲u̲n̲d̲ ̲s̲u̲b̲m̲o̲d̲u̲l̲e̲ of the Transport Station receives
packets from the Packet Handler Module, the packets
themselves being stored in input buffers; pointers
of the packets are stored in the C̲y̲c̲l̲i̲c̲ ̲I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲
(per trunk per precedence).
According to the level of precedence the packets are
assembled into messages, and written on the disc in
the IMF. The entire message including the binary header
is stored.
These pieces of information (extracted from the binary
header) are written into an MTCB:
- Node-to-node serial No.
- Routing mask
- Main type
- Precedence
- Orbit counter
- Length of message
- Pointer of message
After a restart of the sending neighbour messages may
be received twice; a message already received is cancelled.
The node-to-node message protocol is performed, i.e.
for a message (except for ACK/NACK) correctly received
an ACK control message is returned to the sending node,
otherwise (e.g. missing packets) a NACK is returned.
Accepted messages are treated in this way (Inbound
Routing):
- an orbiting ACK/NACK control message for this node
is put into the Transport Queue
- an orbiting ACK/NACK control message for another
node is deleted
- a non-orbiting ACK/NACK control message (for this
or another node) is put into the Transport Queue
- an orbiting control message (other than ACK/NACK)
for this node is put into the CTR-Queue
- an orbiting control message (other than ACK/NACK)
not for this node is put into the MDS-Queue
- a non-orbiting control message (other than ACK/NACK)
for this node is put into the CTR-Queue
- a non-orbiting control message (other than ACK/NACK)
for this MEDE or SIP is put into the MDS or SIP
Queue respectively
- a non-orbiting control message (other than ACK/NACK)
for another N/M is put into the Transport Queue
- an orbiting narrative message is put into the MDS-Queue
- a non-orbiting narrative message for this MEDE
or SIP is put into the MDS-Queue
- a non-orbitintg narrative message for another MEDE
is put into the Transport-Queue
If the trunk is opened, closed or disconnected or if
the neighbour has failed this is signalled from the
Monitoring Module. The IMF-area and the MTCB for each
message (of any precedence level) not fully received
are released.
If one or more packets are missing this is signalled
from the Packet Handler. The IMF-area and the MTCB
are released, and a NACK is returned.
4.1.2.4.5.3 O̲u̲t̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
A possible element in the Transport Queue is signalled
from the Event Module.
The o̲u̲t̲b̲o̲u̲n̲d̲ ̲s̲u̲b̲m̲o̲d̲u̲l̲e̲ of the Transport Station empties
the Transport Queue according to precedence; within
a precedence level delayed messages are given a higher
priority than messages in transit and messages in transit
are given a higher priority than local generated messages
(generated by the NSS, the MEDE or a collocated SIP).
For messages generated locally the orbit counter is
set to its initial value; the value is stored into
the MTCB.
Each message is routed (Outbound Routing), i.e. from
the routing table is found the best neighbour node
according to the destination of the message. The Monitoring
Module informs the Transport Station about trunk- and
neighbour node status. If the node found is not available
or the Trunk Queue is overloaded (and a new routing
table has not yet been received) the secondary (tertiary)
node is found. Necessary copying and routing mask
justification is performed for multiaddress messages,
see Figure 4.1.2.4.5.3-1.
The receipt of an ACK-control message means that the
pointer of the message unacknowledged until now is
released. A possible "special handling" message, which
must be purged before release, is put into the Purge
Queue. NACK means retransmission up to a maximum of
3 times.
The message is supplied with a serial number for the
node-to-node message control. Then it is disassembled
into packets, and a queue element per packet is put
into the T̲r̲u̲n̲k̲ ̲Q̲u̲e̲u̲e̲ according to the precedence level.
The message pointer is put into the Buffer of Outbound
Messages.
Control messages for the present node are put into
the Control Queue.
Information about normal and erroneous situations is
given to the Monitoring Module:
- SCC-statistics: - Trunk Queue Length
- Trunk load (No. of chars.)
- SCC one-hour reports:- Trunk load
- SCC-reports: - Trunk Queue Threshold-alarm
on/off
- Trunk failure
- Node failure
- MEDE-reports: - Hard trunk failure
- Node failure
The Trunk Queue Threshold-alarm on/off situations are
determined in this way:
The Trunk Queue Length is the sum of the No. of queue
elements (packets) in the 7 precedence queues for a
trunk.
When the length exceeds an upper limit an alarm is
reported by the Transport Station via the Monitoring
Module. The first time the length decreases below
a lower limit after an alarm, the alarm is cancelled;
this is done by the Packet Handler.
A Trunk Queue threshold alarm indicates a congestion
situation in the neighbour node.
Congestion in a node may be recognized by the growth
of the Transport Queue of the node, and the growth
of the Trunk Queue of its neighbour nodes beyond some
limit.
If the trunk is disconnected, closed or opened, or
if the neighbour has failed the messages are rerouted,
i.e. they are moved from the Outbound Message Buffer
to the TRP-Q.
4.1.2.4.5.3.1 M̲e̲s̲s̲a̲g̲e̲ ̲R̲o̲u̲t̲i̲n̲g̲
The Outbound Routing of messages is described in this
section.
The information about non-availability of nodes and
trunks is sent by control messages from the nodes to
the SCC.
Each node receives a routing table from the SCC (as
shown in Figure 4.1.2.4.5.3.1-1) each time the topology
or the long term delays have been changed. Congestion
will not produce new routing tables, but merely involve
alternate routing in the neighbour nodes. The table
contains a primary, secondary and tertiary neighbor,
because it must be possible to perform routing also
in the period of time from such changes occur until
new tables are generated and ditributed.
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, oscillations and loopings
of messages may occur. The reasons may be:
- two nodes may disaggree about the availabbility
of a trunk or a node.
- congestion in a neighbour 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 SCC routing algorithm ensures that when using the
s̲a̲m̲e̲ knowledge of the network, then the nodes agree
about the optimum route.
The amount of oscillations and loopings of messages
in the network will be controlled by the "Orbit Counter"
of each message. The counter is a part of the binary
header. When entering the network it is preset to
20; it is reduced by one, when passing a node; reaching
0 a narrative message is transferred to the supervisor
of the NODE/MEDE.
An orbiting ACK/NACK/MICK/MACK is deleted.
The SCC is informed about orbiting narrative messages.
In this way some small amount of oscillations and loopings
is tolerated.
Trunk - or node failures may separate the network into
two or more minor networks, so messages may be locked
out from their destination. In this situation messages
are routed to the local MEDE supervisor.
A message retransmitted from a node to its neighbour
node 3 times without success is transferred to the
supervisor of the NODE/MEDE.
Several copies of a message may be delivered to the
MEDE. The reasons may differ, and the deliveries may
occur independently of each other and at different
moments.
The reasons may be:
o the MEDE is a destination of the message-copy.
o the message copy is oscillating or looping
inside the network.
o the destination of the message copy is cut
off the network.
In the last case a pseudo-MTCB is created and filled.
Whatever the reason is, the (real or pseudo) MTCB is
put into the MDS-Q.
4.1.2.4.6 T̲h̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.1.2.4.6.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Monitoring Module monitors the normal as well as
the erroneous states of the node and the network local
to the node.
Reports are sent to the supervisors of the MEDE and
the SCC. The latter also receives statistics and hourly
reports.
The Monitoring Module is the supervisor of the LTUX';
therefore also some LTUX control is performed by the
Module.
Errors, confirmations and control is signalled to the
Monitoring Module.
Messages generated are put into the TRP-Q. Each message
for the SCC is forwarded to P as well as to Q; in this
way a copy is also made for a standby SCC.
The interface to the LTUX…08… is shown in Figure 4.1.2.4.6.1-1.
Loglines for LTUX configuration, monitoring and control
are created via the I/O-System, the TDX-driver, and
the HOST I/F.…86…1 …02… …02… …02… …02…
4.1.2.4.6.2 M̲e̲s̲s̲a̲g̲e̲s̲ ̲G̲e̲n̲e̲r̲a̲t̲e̲d̲
The Monitoring Module generates messages for the SCC…08…s,
for the local MEDE, and for the neighbour NSS.
The messages for the S̲C̲C̲…88…s̲ are:
- Statistics, which is sent each hour.
- Hourly Report, which is sent each hour.
- Local Network Status Report, which is sent
each time its contents is changed, and on request.
The messages for the l̲o̲c̲a̲l̲ ̲M̲E̲D̲E̲ are:
- Hard and soft trunk failure
- Neighbour node failure
- Trunk opened/closed
- NPDN call-up/close-down
The messages for the n̲e̲i̲g̲h̲b̲o̲u̲r̲ NSS…08… are:
- MICK…08…s and MACK…08…s.
Note that for hard trunk errors the trunk is not used
by the NSS, and new Routing Tables supposing the trunk
to be disconnected are distributed. When the error
is repaired, the failure is reported off.
For a soft error the trunk will still be used, because
the error is supposed to be transient. Therefore the
error will not be reported off.
4.1.2.4.6.3 L̲T̲U̲X̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
The LTUX Supervision covers:
- commands to
- command-responses from
- status requests to
- status-reports from
the LTUX'.
The LTUX…08…s are of the below-mentioned types:
- TRANS
- TRUNK
- NPDN
- DATA USER
- CRYPTO
Supervisory information is transferred between the
Monitoring Module and the LTUX in question via a logline
connecting subdevice #2 as shown in Figure 4.1.2.4.6.1-1.
4.1.2.4.6.4 N̲e̲i̲g̲h̲b̲o̲u̲r̲ ̲N̲o̲d̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
Every 3 minutes each node transmits a socalled MICK
control message to each of its neighbour nodes
connected by an open trunk.
Like all other messages the MICK is acknowledged by
an ACK from the neighbour.
Having received a MICK control message from a neighbour
the node returns a socalled MACK control message.
Also the MACK is acknowledged by an ACK.
The level of precedence is super flash for the MICK
as well as for the MACK. The length is only 18 bytes.
If a message (a MICK,MACK as well as any other control-
or narrative message) has not been acknowledged by
an ACK after having being retransmitted, the neighbour
is reported failed.
The reason for using the MICK control message is that
a long message my be attempted to be transmitted to
a failed node. If more than 3 packets long (the window
of the Packet Handler) the message timer will not be
started, and the failed neighbour will not be detected.
However, a short message like a MICK of its own highest
level of precendence will get its timer started.
But the MICK shares the superflash level with other
messages like ACK and NACK; so it could happen that
3 ACK…08…s or NACK…08…s had been attempted to be transmitted
to a failed neighbour; because ACK/NACK…08…s don…08…t start
a timer, the failed neighbour would not de detected.
That is the reason why the MACK is used.
4.1.2.4.6.5 F̲u̲n̲c̲t̲i̲o̲n̲s̲
Each 30 seconds the LTUX…08… are polled.
Every 3 minutes a MICK control message is sent to each
neighbour connected by an open trunk, if a MACK was
received on the previous MICK.
Each hour the Statistics and the Hourly Report are
filled and forwarded to both SCC…08…s.
On request the Local Network Status Report (LNSR) is
sent to both SCC…08…s.
An Alarm: "Trunk-Queue Threshold Exceeded, on/off",
"Crypto Garbling" or "Orbiting Narrative Message" is
reported by forwarding the LNSR.
When a LTUX responds the polling, the status report
is investigated. In case of hard or soft trunk failure,
NPDN call-up or close-down or change to secondary data-user
route the LNSR is filled and forwarded; also the Nodal
Data File is updated.
A "Neighbour Node Failure" is reported by forwarding
a LNSR and updating the NDF. The Transport Station
is asked to reroute messages for that neighbour, and
MTCB…08…s and IMF-areas for messages partly received from
the neighbour are released. A control message is sent
to the MEDE-supervisor.
When a data-user route should be changed to the primary,
a command is output to the LTUX in question, the NDF
is updated, and the LNSR is forwarded.
In case of normal, alternate-1 or alternate-2 date-user
configuration the LTUX' are reconfigured regarding
a possible NPDN call.
A NPDN call-up or close-down is performed by outputting
the proper command to the LTUX-NPDN. After a successful
call-up the NDF is updated, the LTUX' are reconfigured,
the LNSR is forwarded and a control message is sent
to the MEDE…08…s supervisor.
When a trunk is asked to be opened, the command is
output to the LTUX-TRUNK, -NPDN or -TRANS and the Packet
Handler is asked to restart the trunk. Being restarted,
the MEDE…08…s supervisor is informed, the message counters
are reset, the NDF is updated, and the LNSR is forwarded.
When a trunk is asked to be closed, the command is
output to the LTUX-TRUNK, -NPDN, or -TRANS, the NDF
is updated and the Packet Handler is asked to restop
the trunk. Being stopped the MEDE…08…s supervisor is informed,
the Transport Station is asked to reroute messages
for the trunk, and MTCB…08…s and IMF-areas for messages
partly received from the trunk are released.
4.1.2.4.7 T̲h̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲o̲d̲u̲l̲e̲
4.1.2.4.7.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Control Module receives control messages sent to
the node from the supervisor of the active SCC or from
the supervisor of the local MEDE.
Control messages for the Control Module are put into
the Control Queue by the Transport Station.
ACK/NACK messages sent to the node from its neighbour
nodes are n̲o̲t̲ sent to the Control Module, but entirely
handled by the Transport Station.
Control of the LTUX' is passed on to the Monitoring
Module.
4.1.2.4.7.2 M̲e̲s̲s̲a̲g̲e̲s̲ ̲R̲e̲c̲e̲i̲v̲e̲d̲
The Control Module receives messages from the SCC,
from the local MEDE, and from the neighbour NSS.
The messages from the S̲C̲C̲ are:
- Set Retransmission Threshold
- Set Trunk Queue Threshold
- Routing Table
- Open/Close Trunk
- Change to Primary Data-User Route
- Request for Local Network Status Report.
The messages from the local M̲E̲D̲E̲ are:
- Local Routing Table
- NPDN Call-up/Close-down
- Open/Close Trunk
- Data-User Reconfiguration.
The messages from the neighbour N̲S̲S̲' are:
- MICK's and MACK's.
4.1.2.4.7.3 F̲u̲n̲c̲t̲i̲o̲n̲s̲
A possible element in the CTR-Q is signalled from the
Event Module. If the queue is non-empty, the MTCB
of the first element is read, the message is input
from the disc, and the queue-element, the MTCB and
the file are released.
The threshold is set for a "Set Retransmission Threshold"-
or a "Set TRK-Q Threshold" control message.
A new Routing Table is stored, and the NDF is updated.
In the cases mentioned below, where LTUX-supervision
is required, the control information is passed on to
the Monitoring Module, after a syntactical check has
been performed:
o NPDN Call-up/Close-down
o Open/Close Trunk
o Change to Primary Data-User Route
o Data-User Reconfiguration
Also a request for a Local Network Status Report and
a MICK or MACK is signalled to the Monitoring Module.
4.1.2.4.8 T̲h̲e̲ ̲E̲v̲e̲n̲t̲ ̲M̲o̲d̲u̲l̲e̲
4.1.2.4.8.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Event Module receives external events, i.e. system
answers from the Disc Driver and the TDX Driver, answers
from the Timer- and Checkpoint Process, and signals
from QACCESS. Having received an event, it is analysed
and signalled to an appropriate coroutine within the
Transport Station, Packet Handler, Control Module or
Monitoring Module. Initiating disc- or trunk I/O the
transfer ident is reported to the Event Module; this
is done by storing the ident in the I/O-Transfer Table.
An external event is waited for only when the NSS has
nothing else to do, i.e. there are no coroutines in
the Ready Queue. Therefore, the call of "WAIT-OPERATIONS"
is the very main-waiting point of the NSS.
4.1.2.4.8.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲
External events are received by the Coroutine Monitor
call:
WAIT-OPS
which means that ecternal events are not served until
all internal events have been processed.
4.1.2.4.9 T̲h̲e̲ ̲S̲t̲a̲r̲t̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.1.2.4.9.1 S̲t̲a̲r̲t̲/̲R̲e̲s̲t̲a̲r̲t̲
The Starting Module contains the main entry point of
the NSS. Therefore, this module executes the very
first instructions during a start as well as during
a restart.
There are two differences only in this module between
a start and a restart situation:
First when the Nodal Data File is input during a start
the virgin segment #1 is read. During a restart, however,
the current data of segment #0 is input to the Nodal
Data.
Second the Outbound Message Buffer is reset to a completely
empty buffer during a start. During a restart the
current data of the Checkpoint File is input to the
Outbound Message Buffer.
4.1.2.4.9.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Nodal Data File is opened and input.
The Jack File is opened and input.
The Checkpoint File is opened. The Outbound Message
Buffer is either reset or filled with the Ckeckpoint
File.
The MTCB-Monitor is initialized.
The Coroutine Monitor is initialized.
Finally the Starting Module is stopped.
