top - download
⟦af737b480⟧ Wang Wps File
Length: 77148 (0x12d5c)
Types: Wang Wps File
Notes: AIR CANADA PROPOSAL
Names: »2093A «
Derivation
└─⟦740f46985⟧ Bits:30006253 8" Wang WCS floppy, CR 0097K
└─ ⟦this⟧ »2093A «
WangText
1…0c…1…01…1 1…07…0…0a…0…0b…0…0e…0…0f…0…05…/…0f…/…07….…09….…0d….…05…-…0b…-…02…-…05…,…86…1
…02…
…02…
…02…
…02…
CHAPTER
6
Page
#
DOCUMENT III
TECHNICAL PROPOSAL
Apr. 29, 1982
6.5 N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The ACON software is built using layered concepts.
The NSS constitutes the lowest three environments:
CUE, DTrE and DLE. Each "horizontal" layer consists
of software schedulable tasks which provide similar
services. The packaging of these tasks is done by "vertical"
partitioning such that a group of tasks providing the
total NSS capability can be included in in functional
CR80-processes.
In the following description, we concentrate on the
functions of the NSS without regard to its packaging.
Figure 6.5-1 illustrates this environment.
6.5.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲U̲s̲e̲r̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲(̲C̲U̲E̲)̲
This environment is primarily concerned with providing
an orderly data exchange between two entities in the
higher level software. This orderly exchange is provided
by establishing session-conversations.
This environment is not concerned with the idiosynchrocies
of the individual user. The Network Interface Environment
handles these by providing emulator functions or with
implementation of virtual terminals.
The session-conversations are built on the services
provided by the Data Transmission Environment.
Figure III 6.5-1 …01…Communication Environment
6.5.1.1 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
6.5.1.1.1. S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲E̲s̲t̲a̲b̲l̲i̲s̲h̲m̲e̲n̲t̲
The purpose of the session-conversation establishment
phase is to tie two Session Service Users (SSU) into
a cooperative relationship. To do this the CUE includes
the means to:
- request a session-conversation to another SSU
- receive a request for session-conversation from
another SSU, which it can accept, reject or negotiate
- be notified of the session-conversation establishment
or the rejection of the request
- enable the two SSUs cooperatively to determine
the values of the session-conversation parameters.
These parameters determine:
- type of service (stream or datagram)
- grade of service (reliability, priority etc.)
- throughput (blocksize, degree of flow control)
6.5.1.1.2 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
This phase of the interaction serves for a controlled
exchange of data during the lifetime of the conversation.
Local flow control is provided by CUE so as not to
overload the transport network. This is done by limiting
the size of the outbound queue for each conversation.
When CUE detects that the queue length for a particular
conversation exceeds a predetermined number, it indicates
this to the Session Service User. The latter is expected
to limit the generated output if the ordely exchange
is to be maintained.
Other services for recovering from a possible failures
are provided on request.
6.5.1.1.3 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
This allows the SSU to terminate the conversation without
loss of data. Either SSU may at any time request the
forced termination of the conversation, in which case
data may be lost.
The CUE, optionally, gatheres charging data which is
forwarded to the NSE on termination of a conversation.
6.5.2 D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲
This environment provides standard interfaces and services
which form the basic transport facilities in the ACDN.
The Transport Service Users (TSU) get access to this
facilities by acquiring a Transport Access Port (TAP).
The request for a TAP is processed by the Network Services
Environment. Once a TSU has acquired a TAP, it can
communicate with other TSUs and vice versa.
Chapter 6.5.2.2.1 expands on the addressing aspects.
Notice that TSUs may be identified either e̲x̲p̲l̲i̲c̲i̲t̲l̲y̲
or i̲m̲p̲l̲i̲c̲i̲t̲l̲y̲ in the addressing structure. When a C-PORT-NO
is used the TSU is identified implicitly via the TAP
corresponding to the C-PORT-NO. When the generic name
of the TSU is used, the NSE at the destination is requested
to identify the TSU. If the explicitly named TSU is
known to the destination system (confirmed by directory-lookup),
then it, or an incarnation of it, is activated and
informed of the incoming information. The activated
TSU will then respond to the incoming indication of
a session-conversation by contacting the CUE.
6.5.2.1 D̲T̲r̲E̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The underlining mechanism by which DTrE communicates
is based on datagram technology.
The higher level software is provided with basically
two types of services. T̲h̲e̲ ̲D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲ (DGS) is
based directly on the underlining datagram technology.
This provides a vechicle to base higher level transaction
oriented services.
The V̲i̲r̲t̲u̲a̲l̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲(̲V̲T̲C̲)̲ service provides
enhanced stream oriented services again based on the
underlining datagram technology. This provides a means
for trasporting bulk data.
Figure III 6.5.2.1-1 illustrates this.
Figure III 6.5.2.1-1…01…DTrE Structure
6.5.2.2 D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲(̲D̲G̲S̲)̲
This service provides a one-to-one mapping on the underlining
datagram implementation of the DTrE.
The information entities exchanged within the network
are d̲a̲t̲a̲g̲r̲a̲m̲s̲. A datagram is a data structure of a
defined maximum size consisting of a Datagram Header
(DH) and Datagram Text (DT). The datagram header contains
the source and destination addresses of the datagram.
The datagram text is the actual data to be transported
through the network. This textual data is transparent
to the datagram service.
The DGS only accepts data in the form of Datagram Texts.
Because of the limited size of the datagrams, the service
user is expected to split longer data structures into
a number of DTs. For ACDN a maximum size of 512 bytes
for a DT is suggested. This maximum size will enable
the ACDN to transport the majority of its transactions
in a single datagram.
The DGS provides a fast but not completely reliable
service. If for some reason the datagram cannot be
delivered the transport network will destroy them.
An option is provided whereby the user may request
the delivery confirmation of the datagram. In this
case, the destination DTrE will automatically "echo"
the datagram back to the user - the Datagram Text of
the echo-datagram is shorten to the first ten bytes
of the original datagram. It is expected that the source-user
will have enough information within the echo-datagram-text
to recognize the returned echo-datagram as being the
delivery confirmation on a particular datagram sent
previously.
DGS will provide eight priority levels. The designated
priority is noted in the packet header to ensure that
all transit nodes will respect the priority level of
the datagram. The priority assigned to a datagram affects
the order in which it is transmitted and also the order
in which it is processed in the individual nodes. However,
the algorithms employed ensure that the low priorty
traffic does not get completely blocked.
DGS provides a test mode services. When in this mode,
all datagarams are marked with a user provided mode-indicator.
The interpretation and special processing is in the
users domain.
6.5.2.2.1 A̲d̲d̲r̲e̲s̲s̲i̲n̲g̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The transport network of CRNET provides a number of
Transport Access Ports (TAP) through which the network
users can communicate with one another. The addressing
form reflects the heirarchical structure of the topology.
Figure III 6.5.2.2.1-1 illustrate the various address
formats used.
1) C̲C̲-̲f̲o̲r̲m̲a̲t̲: This format is the normal address format
used to identify another C-NET user who is known to
be attached to a specific TAP.
2) C̲N̲-̲f̲o̲r̲m̲a̲t̲: This is an optional address format used
by a C-NET user to identify another C-NET user, who
is known by a generic name but his specific address
(TAP) is unknown to the source user. The format does
not limit the size of this generic name - however,
it is not expected to be greater than 8 bytes.
3) X̲-̲f̲o̲r̲m̲a̲t̲: This is the normal format used by a C-NET
user to identify a X-NET user. This format is similar
to the CC-format, but has less addressing capability.
(̲a̲)̲,̲ ̲ ̲C̲C̲-̲f̲o̲r̲m̲a̲t̲ (̲b̲)̲,̲ ̲C̲N̲-̲f̲o̲r̲m̲a̲t̲ (̲c̲)̲,̲ ̲C̲X̲-̲f̲o̲r̲m̲a̲t̲
Figure III 6.5.2.2.1-1…01…Addressing Formats
where, AFI: address format identifies
= 0, CC-format or CN-format
= 1, CX-format
level: identifies the C-port-level in the OSI
architecture.
The aim is to facilitate future developments
towards layer level resources management and
con-
trol.
= 0, C-port is at layer 4/5 boundary.
= 1, C-port is at layer 5/6 boundary.
= 2, C-port is at layer 6/7 boundary.
C-NET-NO: identifies the C-NET within the addressed
C-NODE.
= value: from 0 to 15
C-REGION-NO.)
) : identifies the addressed region.
X-REGION-NO.)
- value: from 0 to 255.
C-NODE-NO. : identifies the addressed C-Node.
- value: from 0 to 255.
C-PORT-NO. : identifies the transport access port
(TAP) at the addressed C-NET.
- value: fram 0 to 4095
n̲o̲t̲e̲:̲ this range is extended to three
times the value (12,287), when
supplemented with the use of "level".
C-NAME-LENGTH: the length of the alpha-nummeric generic
name (CNAME)
C-NAME-OFFSET: offset to the actual CNAME string
X-PORT-NO: identifies the TAP at the addressed
X-NET
- value: from 0 to 255
6.5.2.2.2 D̲a̲t̲a̲g̲r̲a̲m̲ ̲F̲o̲r̲m̲a̲t̲
Figure III 6.5.2.2.2-1 shows the datagram format while
figure III 6.5.2.2.2-2 details the optional header-appendix.
o HAL: length of the header appendix/2
o TF: indicates presence of Test Mode (TM) in the
header appendix
.EC. 0, outline datagram
.NE. 0, test datagram
o DFI: datagram format identifies
.EC. 0, the present format
.NE. 0, reserved
o SR: shortest route indicator
.EC. 0, take the shortest route
.NE. 0, split routing
o SD: stream/datagram indicator
.EC. 0, datagram
.NE. 0, stream datagram
o REL: reliability requirement
= 3, highest
= 2, high
= 1, low
= 0, lowest
Figure III 6.5.2.2.2-1…01…Datagram Format
o D: delivery configuration indicator
.EC: 0, no configuration required
.NE. 0, configuration required
o PR: datagram priority
values: from 0 to 7 (7=highest)
o RC datagram rebound count
- incremented every time the datagram passes
through a transit node.
- when this count exceeds a predefined value,
the datagram is considered non-deliverable
and therefore destroyed.
o PS: identifies the protocol used by the higher
level software.
o DA: Destination address
o SA: Source address
o HAP: Optional header-appendix, described below
o DT: Datagram text
- contains transparent user data
Figure III 6.5.2.2.2-2…01…Header Appendix
The following describes the optional header-appendix:
o SI - this area is only present if SD.NE.0.
The area contains necessary stream
information to maintain the Virtual
Transport Connection service.
o TM - this is only present if TF.NE.0. The
value of the byte is used by the user
to specify the test operation.
o DC-NAME/ - alphanumeric text-strings identifying
SC-NAME the users by their generic name.
o Options - specify the various optional facilities
provided by DGS.
For the time being, the following options
are defined:
a) network-time stamp
b) error report
c) return routing information
6.5.2.2.3 D̲a̲t̲a̲g̲r̲a̲m̲ ̲P̲r̲i̲m̲i̲t̲i̲v̲e̲s̲
The DGS provides the following interface primitives:
a) SET ̲TOS
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This primitive is used to set the various parameters
which together define the Type-Of-Service provided
at a DGS-port (TAP).
b) SET ̲MODE
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This sets the DGS-port either in TEST mode
or ON ̲LINE mode.
c) DG ̲DATA ̲REQUEST
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This primitive transfers the user data over
to the DGS.
d) DG ̲DATA ̲INDICATION
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…
This primitive is used by the DGS to handover
the received data to the user.
6.5.2.2.4 D̲a̲t̲a̲g̲r̲a̲m̲ ̲R̲o̲u̲t̲i̲n̲g̲
Based on the address information contained in the datagram
header, the datagram is transported across the ACDN
network to the receiving user. The datagram is forwarded
from node to node, following a path through the network
as indicated by the routing tables in the traversed
nodes until the received is reached.
These routing tables are maintained by a routing algorithm.
The routing tables indicate an ordered list of possible
paths a datagram can take to reach a specified destination
from the present location of the datagram. The list
is ordered by increasing costs. In the ACDN, the principal
factor affecting the cost will be the estimated datagram
transit time.
In most of the present day networks, the routing strategy
is based on the shortest-path (least cost) principle.
In ACDN, the technique known as split-routing will
be implemented. This technique uses both the least
cost paths as well as the non-least cost paths, thus
exploiting all possible paths through the network.
By spreading the traffic in this way, the use of the
total bandwidth available between two nodes is optimized.
Split routing disperses the datagrams at a node, sending
them to one of the possible candidate paths on a probabilistic
basis. The user has the choice of overriding this
mechanism by specifying an appropriate DGS-service.
The ACDN routing strategy is characterised as a c̲e̲n̲t̲r̲a̲l̲i̲z̲e̲d̲
̲a̲d̲a̲p̲t̲i̲v̲e̲ ̲r̲o̲u̲t̲i̲n̲g̲ ̲s̲c̲h̲e̲m̲e̲. The Network Services Environment
in each node will report topological changes to the
NCC. A control algorithm at the NCC uses this information
in conjunction with the knowledge of the total topology
of ACDN to work out a set of new routing tables for
each node. The updated routing tables are then sent
out to the relevant nodes.
The routing algorithm works in the following way.
For each link terminating at a node, the algorithm
maintains both a path length (PL) and a performance
measure (COST) to each destination node within the
same region and to each destination region if the destination
node lies in another region. On the basis of this
the algorithm prepares two routing tables for each
node: a regional routing table and a internodal routing
table.
a) R̲e̲g̲i̲o̲n̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲
This is the first level routing. When the destination
region number is not identical with the local region
number, the routing is performed solely on the
basis of the destination region number.
Figure 6.5.2.2.4-1 shows the format of this table.
The table consists of upto 256 entries. Each
entry contains the information necessary for routing
to the destination region. The entry specifies
upto four possible paths to the destination region.
Each path is specified by a logical path number,
the local C-NET-NO. to which the path is attached
and a Split Count Reset Value (SCRV). This last
parameter reflects the share of the traffic to
be sent on the particular path performing split
routing.
At any given time, the Current Path Offset (CPO)
points to the preferred link for routing. For
every datagram routed via the preferred path, the
Current Split Count (CSC) is reduced by one until
it reaches a value of zero. At this point, the
CSC is reset by copying the reset value into it
and the CPO is changed to point to the next preferred
path in the list. In this way, all the paths are
used to transport the traffic. However, there
are exceptions to this rule: if the datagram has
the highest priority (PR=7) or the explicit request
to take the path with the least cost (SR/0), then
the optimal path is taken unconditionally.
A path in this context represents a group of logical
links. Each link, in iturn, is a group of trunks.
The datagram sublayer of DTrE provides for increased
reliability and capacity of paths by spreading
the path traffic on a number of logical links.
The DLE provides similar facilities at the link
level by spreading the link traffic on multiple
physical trunks.
where,
PN : Logical path number
C ̲NET ̲NO: the local C-NET to which the trunk is attached
SCRV : a reset value for CSC
- reflects the share of split-traffic
to be directed on the path
CSC : counts the number of datagrams routed via
the path during the current cycle.
Figure III 6.5.2.2.4-1…01…Regional Routing Table
b) I̲n̲t̲e̲r̲-̲n̲o̲d̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲
When the destination region is the same as the
local region number, the routing procedure makes
routing decision on the basis of the inter-nodal
routing table.
The format and the use of this table is similar
to that described for Regional routing.
c) I̲n̲t̲r̲a̲-̲n̲o̲d̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲
This form of routing is performed within the environment
of a common operating system. This form of routing
is necessary in the following two cases:
c1) The datagram is destined for another C-NET
within the same C-NODE.
c2) The datagram is to be routed out via a path
attached to another C-NET with the same C-NODE.
The DAMOS operating system provides facilities
for such routing.
6.5.2.2.5 F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲g̲e̲s̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
The purpose of flow and congestion control is to ensure
an optimal orderly flow of traffic through the transport
network.
Congestion in the network may create a loss of traffic.
This controlled loss of traffic is the price paid for
steering the network out of any deadlock situation.
Logically, the best traffic to lose is the traffic
with the highest probability of being lost in the first
place - low reliability traffic. At low degree of congestion,
the network will exercise discretion as to which datagrams
are to be sacrificed. But, if the situation gets worse,
the network will take more drastic actions.
The principle used in congestion control is to prioritize
the traffic that is already in the network over new
traffic entering into the network. Thus, when DTrE
detects that the local buffer resources are running
low, it will block the outgoing (locally generated)
traffic at the Transport Access Port (TAP) and concentrate
on servicing the incoming (transit) traffic. This will
result in the outgoing queues at each TAP getting longer.
Flow control is provided by CUE monitoring the outgoing
queue length at each TAP. When this queue exceeds a
given maximum length, the CUE will notify the Session
Service User (SSU) to stop generating data. Conversely,
when the queue reduces to a given minimum length, the
CUE will notify the SSU to continue generating data.
The actual values of these queue lengths are determined
per TAP basis, depending on the grade of service offered.
The above mechanism is accentuated in more serious
cases of congestion, such that outgoing traffic is
dropped and the associated buffers are confisticated
to support the transit traffic.
6.5.2.3 V̲i̲r̲t̲u̲a̲l̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲(̲V̲T̲C̲S̲)̲
The VTCS provides an enhanced service based on the
Datagram Service (DGS) described above. The primary
purpose of VTCS is to provide the higher level users
with a reliable end-to-end controlled stream oriented
data transfer.
The services provided are divided into three main groups:
- connection establishment
- data transfer
- connection termination
a) C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲E̲s̲t̲a̲b̲l̲i̲s̲h̲m̲e̲n̲t̲ ̲p̲h̲a̲s̲e̲
The users are provided with facilities to dynamically
create transport connections. At this time the
users may request different types of services such
as:
- the reliability of the connection, i.e. whether
the VTCS must retain copies of messages for
retransmission.
- the priority of the data transfer
- the throughput rate, which will influence the
end-to-end flow control window-size and the
degree of multiplexing with other data streams.
- maximum size of messages
The same addressing scheme as described in 6.5.2.2.1
is used to identify users in this service.
The type of service parameters are defined in cooperation
between VTCS and both the service users.
On the successful completion of this phase, the
two relevant users are provided with a two-way
simultaneous path for data transfer and, optionally,
a similar path of control purposes (expedited data
path).
b) D̲a̲t̲a̲ ̲t̲r̲a̲n̲s̲f̲e̲r̲ ̲p̲h̲a̲s̲e̲
This phase controls the orderly transmission of
stream oriented traffic. The messages received
from the source user are segmented into smaller
units. These segments are sent to the destination
VTCS via the Datagram Service. The destination
VTCS reassembles these units in the correct sequence
before relaying the message to the destination
user.
An end-to-end window mechanism is used to control
the flow of data through the network. For normal
data flow this window size is negotiated at connection
establishment time. For expedited data, if selected,
the window-size is fixed to one.
c) C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲t̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲p̲h̲a̲s̲e̲
Both users of a connection may, regardless of the
current activity, request that the connection be
terminated. To terminate properly it is assumed
that the users have ended their conversation prior
to this request.
When a request for termination is issued, all data,
both normal and expedited, not yet delivered to
the users are discarded.
Should the VTCS not be able to maintain the service
requested at establishment time, the VTCS may terminate
the connection and notify the involved users.
6.5.2.3.1 V̲T̲C̲S̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲s̲
The services provided and the protocols used to provide
these services are very much influenced by the current
work being carried out in the international standards
bodies.
The following documents are particularly relevant:
a) Draft connection-oriented transport service definition
ISO TC97/SC16 N860
b) ECMA-72, Transport protocol
c) Draft connection-oriented basic transport protocol
specification ISO TC97/SC16 N861
6.5.2.4 D̲a̲t̲a̲ ̲L̲i̲n̲k̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Data Link Environment (DLE) supports the Balanced
Link Access Protocol (LAPB) which is specified in CCITT
recommendations X.25 and X.75.
This protocol ensures error free full duplex transmission
of frames on a single link, from one C-NODE to another,
except for the very rare case where bit errors are
not detected by the frame sequence check.
The protocol is implemented in firmware on the Line
Termination Unit (LTU) board, which connect trunks
to the CR80 computer.
To increase the reliability of the links, Multilink
Link Procedures (MLP) will be implemented.
6.8 I̲n̲t̲e̲r̲n̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The main task of the gateway (GWY) is to act as the
physical and logical link between the ACNC and the
ACDN, see Figure III 6.5.5-1.
As seen from the ACNC the gateway must look like several
ICC'S with CRT's and printers.
As seen from the Nodal Switch Software of the collocated
node the Gateway must look like any other subsystem
interfacing the network.
Therefore the Gateway is a protocol converter between
the ICC- and the NSS-protocols.
It also acts as a multiplexer or speed converter of
several ICC subsystems (of 9.6 Mbps each) and one CCI
subsystem (Communication Control Interface).
Finally the Gateway is a converter because messages
must be converted to and from the Virtual Terminal
Protocol entirely used inside the ACDN.
Fig. III 6.8-1…01…The Gateway (GWY) and its Surroundings
6.8.1 A̲C̲D̲N̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
o The interface between the Gateway and the old ACNC
is characterized by:
- several 9.6 Mbps lines
- ICC protocol (AC200) on each line incl. IMA.
- entire messages are stored and forwarded
- in case of error the entire message is retransmitted
- messages are divided into segments.
6.8.2 N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
o The interface between the Gateway and the new ACDN
Packet Switched Network is characterized by:
- S-net Connection
- Message level protocol
- A number of logical channels will be established
for virtual calls as well as possible permanent
virtual circuits through the network
- Virtual Terminal Protocol
The interface is shown on figure III 6.8-2.
Fig. III 6.8-2…01…The ACNC and the Network Interface of the Gateway
6.8.3 M̲o̲d̲u̲l̲e̲s̲ ̲o̲f̲ ̲t̲h̲e̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
6.8.3.1 T̲h̲e̲ ̲I̲C̲C̲ ̲M̲o̲d̲u̲l̲e̲
The ICC Module is divided into a number of co-routines
each performing the task of acting like an intelligent
Communications Concentrator as seen from the ACNC.
Messages are exchanged with the CCI Module by means
of Message Queues.
a). T̲h̲e̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲M̲o̲d̲u̲l̲e̲
The Communications Control Interface Module (CCI)
interfaces the Nodal Switch Software.
Virtual Circuits to hosts, terminals and printers
are created and dismantled when necessary initiated
from this module.
Messages are exchanged with the ICC co-routines
by means of Message Queues.
b). T̲h̲e̲ ̲H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲o̲d̲u̲l̲e̲
The conversion to and from the Virtual Terminal
Protocol entirely used inside the ACDN is done
by the High Level Service Module.
c). T̲h̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲M̲o̲d̲u̲l̲e̲
The Gateway is monitored from this module which
generates Statistics (host-, terminal-, and printer
connections) and error reports. Possible controlling
information too is received by the module.
d). T̲h̲e̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲ ̲M̲o̲d̲u̲l̲e̲
This module will perform all recovery necessary
for the GWY to be restarted after a Gateway-failure.
The recovery will be done from appropriate checkpoint
information.
6.9 E̲x̲t̲e̲r̲n̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲,̲ ̲E̲N̲A̲S̲
The system and application software for supporting
external network access is implemented in different
subsystems. The high level procedures are implemented
in the NCPs partly in the EMH, whereas the lower level
software for link control etc. is implemented in the
NSPs in order to provide external network access to
the most appropriate node.
6.9.1 A̲R̲I̲N̲C̲ ̲a̲n̲d̲ ̲S̲I̲T̲A̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Christian Rovsing has extensive experience in implementing
communication procedures like those defined by ATA/IATA
and used on ARINC and SITA networks. This experience
has been gained in military programs like FIKS and
CAMPS, where the NATO defined ACP127 communications
procedures have been implemented. The ACP127 is many
similarities to the ATA/IATA procedures, but it is
more complex, e.g. the ACP127 procedures includes 16
different format lines with different optional and
mandatory parameters per line.
The utilization of both 5-bit and 7-bit coded character
set and the conversion between these is also well known
from the military environment.
The validation of an ATA/IATA message is performed
by the ENAS at the EMH. An ATA/IATA message has the
following gour mandatory sections:
- Address
- Communications reference
- Text
- Ending
The elements of the Address section are
- Start ̲of ̲Address (Mandatory)
- Priority Indicator (Optional)
- Addressee Indicator(s) (Mandatory)
- Alignment Function (Mandatory)
- End-of-Address (Mandatory)
The elements of the Communications reference section
are
- Message Origin (Mandatory)
- Message Identity (Mandatory)
- Special Service Address (Optional)
The elements of the Text section are
- Start ̲of ̲Text (Mandatory)
- Text (Mandatory)
- Alignment (Mandatory)
- End-of-Text (Mandatory)
- Communication Control Information (Optional)
The elements of the Ending section are
- Spacing signal (Mandatory)
- End-of-Message signal (Mandatory)
- Message Separation signal (Mandatory in some cases)
In addition to the above mentioned elements, supplementary
optional information might be required in special cases.
The definition of all elements are different depending
on which alphabet has been used. Both the asynchronous
and the synchronous link control procedures can be
applied.
Asynchronous link control is performed by use of the
following control codes
- VA, Validate Action Code
- IA, Invalidate Action Code
- SA, Suspend Transmission Code
Synchronous link control utilizes a more extensive
set of control information and procedures to ensure
error free transmission.
The link level control software will be installed in
the NSP in other to connect the external networks.
6.9.2 C̲N̲T̲ ̲a̲n̲d̲ ̲S̲i̲m̲i̲l̲a̲r̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲s̲
Messages received from the CNT network are also checked
when interfaced to the ACDN. The structure of a CNT
message is however very simple, i.e. an envelope defined
the start-of-message, the recipient followed by a free
format text and ended by a end-of-message designator.
ENAS located in the NSP controls polling and calling
of selectorised teletype terminals connected to multi-drops
full-duplex or half-duplex low-speed asynchronous lines.
ENAS supports 81D1, 83B3 and similar teletype protocols.
Global line and terminal control is exercised by the
active NCC similar to the control exercised on other
node terminations. ENAS recognizes and initiates appropriate
controlling action for open circuit, mark hold, or
terminal response failure. Line and terminal status
is dynamically maintained in both ENAS and NCC.
Terminal transmission of ATA/IATA formatted traffic
is assembled by ENAS and transferred, upon receipt
of EOM, to the EMH for validation, routing and mass
storage retention. An input message acknowledgement
is generated by the EMH and transferred via NSS for
relay to the originating terminal.
Under control of a poll-call ratio structure, ENAS
solicits the EMH to transfer, via the supra-bus, complete
messages for delivery on the teletype terminal network.
ENAS selects addressed terminals, initiates character
transmission and if required, returns requeue status
to the EMH in accordance with protected message philosophy.
In order to establish a network compatibility at the
low level between ACDN and the CNCP Telex network,
on intelligent micro telecontroller is proposed.
The Model 2000 Micro Telecontroller, a general purpose
programmable controller "GPPC", is programmed to interface
Air Canada's new data network ACDN to the CNCP-Telex
Network.
The GPPC provides for the "Incoming" and "Outgoing"
telex connections and converts the internal ACDN data
codes to 5-level Baudot and vice versa, as well as
changing the transmission speeds automatically.
The GPPC can interface to EIA/V24 lines and DC-Loops,
and is capable to receive telex calls as well as establishing
automatically outbound calls, providing also for "answerback"
verifications.
The GPPC, upon receiving a call request from ACDN for
an outgoing call, automatically sets up the telex connection
in the following manner:
a) AC-Data Network Call Request - ESC, Dial Nbr.,
STX
- Called Answerback,
ETX
b) GPPC stores Call Request - EOT, NACK, DC3
and acknowledges with
c) GPPC sets up call - Seizes Telex Line
- Transmits selection
format
- Waits for call
con-
firmation
- Compares received
answerback
- Transmits its own
answerback
d) GPPC switches the Telex - DC 1
connection to originator
e) AC Data Network transmits - SOH, Block Nbr.
1
- Block N
- ETC
f) AC Data Network disconnects - DC 3
call
g) GPPC disconnects call - clears telex line
and returns to
idle
A number of safeguards are built into the GPPC-program
to prevent false telex connections, to detect busy
conditions and time-outs, and to provide reports to
the AC-Data Network concerning correct delivery of
messages.
The GPPC has inherent buffer storage of 2048 bytes
for message storage, and the data flow is controlled
with X-ON X-OFF transmitted towards the originator
in the ACDN.
While the GPPC is in the "outbound" call mode, incoming
calls can not be accepted.
The GPPC continuously monitors the telex line. Upon
an Incoming Call Request, the GPPC will inhibit any
outbound calls, and accept the incoming call as follows:
a) GPPC accepts call - sets EIA/V24 control
leads
- X-OFF, DC3, transmitted
to the AC Data Network
to inhibit outbound
calls
b) GPPC requests and validates
Calling Party Answerback - transmits Fig. D towards
telex network.
- stores the Answerback
- compresses the Answer-
back to alpha/numerics
space character
c) GPPC connects call to
AC Data Network, sends - SOH, CR LF, Calling
Answerback, STX
d) GPPC sents its I.D. - transmits its own
Answerback
e) GPPC converts text - message characters
received from Telex
are converted from
Bau-
dot to ASC II towards
the AC Data Network
in
transparent mode.
f) GPPC disconnects call - upon receipt of type
B
disconnect
- upon time out after
60
sec. delay
- EOT, DC1 towards the
AC
Data Network
The GPPC returns to its "idle" mode and is ready to
receive or originate new calls.
6.9.3 P̲u̲b̲l̲i̲c̲ ̲P̲a̲c̲k̲e̲t̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲ ̲D̲a̲t̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲
Christian Rovsing will provide to Air Canada the access
capability to interface to any public or private packet
switching network which can be interfaced through X.75.
This standard, which has been issued by CCITT, is the
internationally recommended interface between different
packet switching network.
The X.75 gateway software is equipped with Multi link
Procedures (MLP) which enable the traffic over the
connection to be diversified on more than one connection.
This provides higher throughput capability and better
reliability.
The X.75 protocol might have to be customized by Air
Canada, if billing and statistical data has to be transferred
from the external network to ACDN or vice versa.
6.9.4 I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲f̲o̲r̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲e̲x̲t̲ ̲(̲S̲M̲T̲)̲
Christian Rovsing can optionally offer to implement
a syntactical interpreter for SMT, when these are received
in the ACDN. From military projects Christian Rovsing
has achieved great experience in implementing advanced
man machine interfaces comprising also utilization
of predefined formats, where the structure of a predefined
format can be defined in a way to both satisfy actual
differences and similarities in applied messages.
Christian Rovsing suggest to implement an interpreter
as part of ENAS which will validate SMT according to
tables defined by the following symbols.
a represents a single alphabetic character
f represents a single numeric character
m represents mixed alpha (A through Z) and figures
(numerics 0 through 9); excludes other characters
t represent any characters, numeral of special
value
() brackets frame indicate optionality
(*N*) indicates an upper limit of a duplication factor
(*M..N*) indicates lower and upper limit of
duplication factor
*F indicates a figure shift (in alphabet No. 2)
*L indicates a letter shift (in alphabet No. 2)
*S indicates a space
*LR indicates a carriage return
*LF indicates a line feed
Where a keyboard is to be spelt the format is specified
in upper case characters, numerals, a slash or period.
6.10 N̲E̲T̲W̲O̲R̲K̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲P̲A̲C̲K̲A̲G̲E̲
This section describes the software implementation
of the network control and supervision functions described
in section 4.8.
The Network Control Software (NCS) realizes the Network
Services Environment (NSE). NCS executes on the NCC
processors. NCS of the active NCC has the global network
control responsibility, although certain control functions
may be originated elsewhere than at the NCC.
6.10.1 N̲C̲S̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
The NCS architecture is illustrated in figure 6.10.1.
Figure 6.10.1 NCS Architecture
6.10.1.1 N̲C̲S̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The global ACDN network control responsibility resides
with the Network Control Software entities of the NCC
Network Services Environment (NSE).
To enable this global control and monitoring each major
functional entity of the NCS package communicates with
peer level entities in each ACDN nodal subsystem through
permanent transport connections established at system
initialization time.
6.10.1.2 N̲e̲t̲w̲o̲r̲k̲ ̲T̲a̲b̲l̲e̲s̲ ̲a̲n̲d̲ ̲F̲i̲l̲e̲s̲
The global definition of the ACDN network and its environment
is contained in the following NCC/NCS tables:
o Global Network Table
o User Profile Table
o Operator Profile Table
o Terminal Profile Table
Infrequently accessed data are kept on NCC disk storage
files:
o ACDN Network Definition File
o User Profiles File
o Operator Profiles File
o Terminal Profiles File
o Statistics Data File
The format and contents of the Global Network Table
are described in section 6.4.
6..10.1.3 R̲o̲u̲t̲i̲n̲g̲ ̲P̲r̲i̲n̲c̲i̲p̲l̲e̲s̲
This section presents the underlying scheme for implementing
an adaptive routing strategy.
An adaptive routing scheme with a centralized routing
calculation and a decentralized routing selection is
applied.
The routing scheme adapts to the current network topology
and the current load of the internodal trunks.
Routing calculation is performed centrally, and the
resulting routing tables are distributed to each node.
The routing table - which at the arrival at the node
represents the past - in conjunction with the nodes
instantaneous view of the load of the trunks, makes
up the basis for route selection.
6.10.2 M̲a̲j̲o̲r̲ ̲N̲C̲S̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The NCS package consists of the following major software
components:
o Network Operator Services
o System Configuration Services
o Network Access Services
o Session Services
o User Services
o Alarm and Event Processor
o Network Test Services
o Statistics Support Services
o Network Recovery Services
The functions of these services and the various component
interfaces are described in the following sections.
6.10.2.1 N̲e̲t̲w̲o̲r̲k̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The Network Operator Services (NOS) are responsible
for providing the operator man-machine interfacing
allowing the network operator to control and monitor
the overall ACDN activities.
NOS consist of two subcomponents:
o Command Interpreter
o Display Processor
These support operator input/output in all ACDN network
components.
6.10.2.1.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲M̲I̲)̲
The CMI will exist in one incarnation (task) per defined,
active operator position in the ACDN network components,
both NCC supervisory and engineering work positions.
Thus the CMI can receive input both from standard VDU
and colour display keyboards.
Further, the CMI may be configured for communicating
with remote operators, through a standard transport
connection. This feature is applied in the case of
netork supervisory control and monitoring exercised
from a nodal engineering position.
The CMI component performs non-semantic processing
of operator input/output including:
o command input processing
o parsing and classification
o routing of commands to appropriate handler
o response output processing
Command inputs are routed to the software module in
charge of the function related to the command input.
The scope of these commands is described in chapter
4 (see section 4.6).
Further, the CMI is involved in a number of secondary
functions related to the basic operating system. These
are:
o Management processes
o Management of local devices (disk, tape, etc.)
6.10.2.1.2 D̲i̲s̲p̲l̲a̲y̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲
This software entity performs functions which allow
an operator to display control and status related information.
The Display Processor is intended to interface applications
to different types of VDUs:
o Graphic status display VDU (Intercolor 8001) display
station. This is described in section 4.4.2.
o Standard VDUs presenting formatted input/output.
The display processor provides predetermined picture
definitions to applications requiring operator I/O.
6.10.2.2 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The System Configuration Services (SCS) provide the
functions needed for establishment and maintenance
of a current composition of ACDN, including:
o internal resources (nodes, trunks, routing)
o external resources (lines, concentrators, devices,
hosts and applications)
The SCS program manages the Global Network Table (GNT).
Initially, the GNT is retrieved from the current Network
Definition File. Table operations on GNT, as will take
place when changes to the ACDN network occur, are performed
in memory. However, online configuration changes may
be performed on the Network Definition File also.
The GNT contains all information related to the internal
and external networks. SCS provides the GNT distribution
function for transfer of subparts of GNT to nodal points
needing knowledge only related to their local environment
(local trunks and external resources).
Configuration information is exchanged between SCS
and the local internal and external resource managers
of each participating node through permanent transport
connections setup at system initialization time. These
connections are used for overall distribution of subsections
of the GNT relevant to the scope of individual nodes.
The major functions performed by SCS include:
o Management of Network Definition File and Global
Network Table
o Local Network Table distribution
o Internal resource management (nodes and trunks)
o External resource management (lines, concentrators,
devices, hosts and applications)
o Routing calculation
Changes to configuration and resources occurring locally
at a node are automatically reported to SCS, which
updates the GNT and informs the Alarm and Event Service
process for presentation to the network supervisor.
6.10.2.3 N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The Network Access Services (NAS) are responsible for
validating logon requests to ACDN. Both network operators
and ACDN users are being validated by this software
entity. The logon validation is based on operator and
user profiles.
The logon procedure for network operators and users,
implemented by NAS, as well as general security aspects
are described in section 4.5.
6.10.2.4 S̲e̲s̲s̲i̲o̲n̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
Session Services (SS) processes requests for session
establishment and termination. During the life time
of a session it is managed by the SS software entity.
Session status is maintained in the GNT.
SS includes cross domain functions enabling it to communicate
with host access methods (VTAM, CMS1100) during session
establishment.
The major SS functions include:
Operator commands:
o Initiate/terminate/status of session
o Initiate/suspend/resume/terminate/status of connection
o Set session limits
Internal commands:
o Route session requests from User Services (US)
either to a Cross Domain Resource Manager (CDRM)
emulator or to a session manager depending on destination
end user type
o Switch messages between session managers intended
for address resolution purposes
o Receive accounting information at session initiation
and termination, and write an account record.
6.10.2.5 U̲s̲e̲r̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The User Services (US) software entity communicates
with all ACDN user terminals on their network control
session.
The following functions are provided by the US software
entity:
o Logon support, validation of user and selection
of default parameters based on user profile, mainframe
application selection, output of logon news and
indication of waiting messages in an electronic
mailbox.
o Logoff support.
o Message switch to other user or to message switch
application.
o Operator notification from user.
o Message broadcasting from operator to group of
users or terminals.
6.10.2.6 A̲l̲a̲r̲m̲ ̲a̲n̲d̲ ̲E̲v̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲
The Alarm and Event Processor (AEP) is the global receiver
of all event messages generated in ACDN. The alarm
system is described in section 4.8.6.
Any event which requires operator notification is routed
to AEP.
The AEP software entity is the manager of the event
log list (file). Entry of events into the log is based
on an event classification scheme.
The AEP module interfaces to the Network Operator Services
for presentation and control of alarms, alerts and
notice events contained in the event log. Through this
interface event notification is routed to the operator
position that has reserved that particular type of
event.
6.10.2.7 N̲e̲t̲w̲o̲r̲k̲ ̲T̲e̲s̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
Network Test Services (NTS) consists of several subcomponents
organized as applications of the network services environment.
NTS includes the following software entities:
o Data Unit Trace
o Loop Test
6.10.2.7.1 D̲a̲t̲a̲ ̲U̲n̲i̲t̲ ̲T̲r̲a̲c̲e̲
Trace applications may be started to receive trace
of all data units passing a given point.
The following traces may be selected:
o Channel data
o Line, concentrator, cluster, or terminal
o Virtual circuit
o Connection
o Session
Trace applications may write the trace data to common
or separate files.
6.10.2.7.2 L̲o̲o̲p̲ ̲T̲e̲s̲t̲
Loop testing is concerned with testing the proper functioning
of different parts of a communication line:
o local loop at LTU
o looping at local modem
o looping at remote modem
The loop test application in the NCC may exercise the
outgoing NCC trunks - or it may request nodes to perform
loop tests on designated links. The positive or negative
test result is returned to the NCC loop test application.
6.10.2.8 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
Statistics Support Services (SSS) are responsible for
collecting statistical data, for making a first level
analysis of the collected data and for producing reports
of network performance characteristics. These functions
are provided by the SSS components:
o Statistics management and collection
o Statistics report generation
6.10.2.8.1 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
Statistical data are constantly collected by the nodes
for all resources which have been designated in a START-STATISTICS
command or which are part of the permanent statistics
recording. At regular intervals or when a threshold
is exceeded the statistics records are time stamped
and sent to the NCC where they are written to the designated
files.
The latest statistics record values for each resource
are averaged with the already stored values according
to the formula:
stored-val:= ((n-1) stored-val+new-val)/n
where n is specified at system generation.
The responsibilities of statistics collection are:
o switching on/off statistics collection in subcomponents
o receiving statistics data (on permanent transport
connections)
o performing a first level data compression
o safe storing statistics on disk files
o forwarding statistics to the NMH processor.
6.10.2.8.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲R̲e̲p̲o̲r̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
The Report Generation (RG) application can print (display)
in readable form the entries of selected resources
from any statistical file. RG is activated on a regular
basis to produce timed reports and upon explicit operator
request.
6.10.2.9 N̲e̲t̲w̲o̲r̲k̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
Network Recovery Services (NRS) are responsible for
initiating the required actions in case of failure
in the ACDN. The ACDN Recovery and Redundancy functions
are described in section 4.14.
The NRS software entities implement:
o checkpointing (internally in subsystem and network
globally, i.e. NCC-NCC checkpointing), i.e. preparation
for recovery.
o failure validation
o management of switchover to redundant elements;
i.e. restart and recovery.
In more detail the responsibilities of Network Recovery
Services include:
Local management:
o PU-PU checkpointing
o PU switchover
o Suprabus switching
o Mirrored disk management
Global management:
o NCC-NCC checkpointing
o NCC switchover to backup NCC
The above recovery functions are described in detail
in section 4.14.
6.11 N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲H̲o̲s̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The Network Management Host (NMH) is a general purpose
computer connected to the backbone network as an ordinary
host processor.
The services offered by the NMH are to a great extend
standard software products as language processors and
software maintenance utilities. All services are controlled
by the DAMOS multiuser system which can provide service
for an unlimited number of concurrent users.
6.11.1 N̲M̲H̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲a̲n̲d̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
o The services of the NMH are offered to any user
at any terminal connected to the backbone network.
The basic services offered are:
- Software development and maintenance facilities
- Network modelling software
The NMH is connected to the backbone network via a
supra bus link. Softwarewise the NMH contains support
for the "File Transfer Protocol" and "Virtual Terminal
Protocol".
Thus the NMH is able to service any user at any terminal
in the backbone network. The access to the NMH is controlled
by a session control layer.
Directly connected to the NMH there is the following
standard peripheral equipment:
- Disc unit with 80 Mbyte moving head and 2 Mbyte
fixed head capacity
- Disc unit with 80 Mbyte exchangeable disc pack
- Line printer for 600 LPM
- Magtape unit
- Floppy Disk
- 3 Visual Display Units
The functional areas of the NMH application are the
following:
- Software development, maintenance and configuration
control
- Maintenance of the data bases for: Network Configuration
and Network Inventory List
- Downline loading of software and configuration
data
- Processing of data for statistics and for cost
and billing.
- Network modelling functions and automated test
and emulation functions for real-life tests.
6.11.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The NMH provides all the tools necessary for software
development and maintenance.
The following programming languages are available for
the CR80M computers:
- SWELL, which is an intermediate level systems programming
language
- PASCAL, which is a general purpose high level programming
language
- COBOL, which is a high level language for administrative
application programming.
Furthermore, the new DOD standard programming language
ADA will be available for the CR80M computers from
1984.
The NMH software development and maintenance package
comprises the following functions:
- Source test editor
- Language processors for: SWELL, PASCAL, COBOL
- A comprehensive set of file-handling utilities
(copying, moving, patching, comparing, backup,
etc.)
- All the libraries necessary for software development
and maintenance.
An extensive description of all standard software available
for the CR80 computer is found in the CR80 Minicomputer
Handbook section 4.
6.11.3 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲
The Data Base (DB) implemented in ACDN is a set of
data structures giving the physical and logical relations
between items in the ACDN. The key items in the DB
are as follows:
C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲i̲n̲v̲e̲n̲t̲o̲r̲y̲ ̲d̲a̲t̲a̲
- End user devices (e.g. terminals, printers, host
channels) - each device has associated a logical
identification, a physical path (relates to inventory
items attributes) and an attribute list (e.g. type,
priviledges, protocol).
- Inventory Items - a list of all "line replaceable
units" in the access networks and, the backbone
network ordered per equipment type. Each unit has
a record defining all external logical and physical
connections with cross reference to the device
path definitions for consistency checking.
- User catalogue - each user allowed access to the
network is identified by a user profile, i.e. a
user ID, password, user attributes (e.g. type,
priviledges, priority).
S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲a̲n̲d̲ ̲b̲i̲l̲l̲i̲n̲g̲ ̲D̲a̲t̲a̲
- For each transaction type, there will be statistical
and billing information including host terminal,
user identification plus time information.
M̲o̲d̲e̲l̲l̲i̲n̲g̲ ̲D̲a̲t̲a̲
- Test configuration (e.g. terminals, concentrators,
nodes and host) including their interconnection.
- Traffic profiles for terminals and hosts including
time and length distribution.
Subsets of the data base exist in three versions at
the NMH. The previous version, the current version,
and the version under update - only the latter is subject
to any changes or updates. The data base is based on
the index sequential access method: CRAM. Updates may
be performed interactively or in batch mode.
6.11.4 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲U̲s̲e̲r̲ ̲G̲r̲o̲u̲p̲s̲
Two different user groups of the DBMS are foreseen.
The first group comprises the experienced programmers
and the DB administrator who are responsible for the
integrity of the DB. The other group consist of technicians
who are interested in the configuration subset of the
DB.
D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲U̲s̲e̲r̲s̲
The experienced users of the DB, has a detailed knowledge
of the structure of the DB. Their requirements to a
DBMS are:
- Query language facilities which can also be used
for DB modifications
- Optimization capability which allows the experienced
user to utilize his detailed knowledge of the DB
structure to the full extend.
M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲U̲s̲e̲r̲s̲
The technicians who are responsible for the hardware
components of the ADCN, i.e. the configuration have
a different requirement to the DBMS:
- Specific retrieval capabilities to the configuration
DB.
- Specific and limited change capability to the configuration
DB
- Optimal access capabilities with small response
times
- Guarantee for DB integrity during exercise of the
above capabilities.
The DBMS offered by Christian Rovsing will serve both
user groups. The maintenance user will have specific
and special tailored access capabilities, which can
be expanded by AC is required in the future. The development
users, i.e. programmers will get the total tool set,
developed and used by Christian Rovsing during implementation.
6.11.5 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲T̲o̲o̲l̲s̲
Instead of a standard and general purpose DBMS, Christian
Rovsing will offer to Air Canada an extensive set of
versatile tools, which when used by experienced users
will provide great flexibility in many different aspect,
e.g. query situations with complex dicision parameters
followed by data base modifications. Also optimization
situations where the experienced users detailed knowledge
of the DB can be performed due to the high flexibility
of DBMS.
It is Christian Rovsing's experience, that modern software
development strategies like structured programming
combined with good documentation techniques is more
beneficial to an experienced programming organization
like Air Canadas, than the application of a more or
less rigid DBMS which tend to obscure the actual data
organization and which might only have limited optimization
capabilities.
The set of tools which Christian Rovsing will offer
as a DBMS are aimed specifically at Air Canadas use.
They include:
o Processing of the total DB is a sequential fashion
to provide
- selection of subsets of the DB for downline
loading to other subsystems
- printout of the total database for manual inspection.
- foundation for user written query statements.
- optimization of DB in connection with reorganization.
o Optimal processing of any subset of the total DB,
like
- configuration DB
- inventory DB
- statistical DB
- billing DB
All the tools of the DBMS will be programmed in the
high level language Pascal, and all the capabilities
inherent in this language will be available for the
user.
Christian Rovsing will provide a source code library
of all the components necessary for performing the
above mentioned tasks. This includes definition of
all record types and print modules for each type of
record. The following example written in pseudo code
will demonstrate how the tools can be applied.
QUERY:
DEFINE ICC ̲RECORD,
Module 1 ICC ̲FIELD1,
retrie- ICC ̲FIELD2;
ve
DEFINE TERMINAL ̲RECORD,
from TERM ̲ID,
libra- TERM ̲TYPE,
ry TERM ̲TEST ̲MODE ̲INDICATOR;
LOOP:
READ NEXT ̲RECORD INTO RECORD
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
User IF RECORD = TERMINAL ̲RECORD THEN
written IF TERM ̲TEST ̲MODE ̲INDICATOR = MODE1 THEN
state- CALL PRINT ̲TERMINAL ̲RECORD;
ments
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
ELSE GOTO LOOP;
Module 2 PRINT ̲TERMINAL ̲RECORD:
retrieved PRINT(TERM ̲LID, TERM ̲TYPE, TERM ̲TEST ̲MODE
̲
from li- INDICATOR),
brary END PRINT ̲TERMINAL ̲RECORD;
PRINT ̲ICC ̲RECORD;
PRINT(FIELD1, FIELD2);
END PRINT ̲ICC ̲RECORD;
END QUERY;
Fig. III 6.11.5-1
In order to make a printout of all terminals with a
specific test mode indicator, all the programmer has
to do is to retrieve two modules from the source library
and insert the requested selection criteria before
submission for compilation and executing. This can
be controlled interactively from a CRT.
The software development tools including on line library
functions and source code editing will minimize the
extra effort required by the programmer, when using
this query facility and will be a small expense compared
to the great flexibility provided. As an example it
will only require a few statements to perform a bulk
update of all terminal with some specific characteristics.
If Air Canada express any concern over giving to much
flexibility to the programmers, Christian Rovsing is
also willing to deliver a query language version where
the library modules are totally hidden from the user
and where the compilation and execution is performed
automatically. This will provide a more traditional
interface to the user.
In order to provide initial query language facilities
to the maintenance user, Christian Rovsing will provide
retrieval capabilities of any individual record type
within the configuration DB. The terminal user only
has to enter the record type, i.e. terminal, concentrators
etc. and the identification key of that record.
Future enhancement, which might give the maintenance
user capabilities like simple updates in specific areas
can be implemented by Air Canada, when requirements
are identified.
6.11.6 R̲e̲p̲o̲r̲t̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
Report generation capabilities are really enhancements
to the query facilities. In addition to the sequential
processing of the data base and the selection criteria,
you might have to collect all printout information
for sorting before further processing including accumulation,
counting etc. followed by the final printout.
Modern structured programming techniques have shown
how this can be done in a straight forward way in normal
high level languages without relaxation of any of the
capabilities found in high level languages. Specialized
report generators normally either contain output format
limitations or they are so complicated to use that
no time saving is obtained.
Christian Rovsing will develop data base printout programs
showing how this technique works.
6.11.7 N̲e̲t̲w̲o̲r̲k̲ ̲M̲o̲d̲e̲l̲l̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲a̲n̲d̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲f̲o̲r̲ ̲A̲u̲t̲o̲m̲a̲t̲i̲c̲
̲N̲e̲t̲w̲o̲r̲k̲ ̲T̲e̲s̲t̲s̲
o Network modelling and real life network tests are
addressed in this section.
Testing the consequences of network topology changes
can be performed by means of the "Network Model" which
is mathematical model of network or by means of the
"Automated Test & Emulation System" - ATES.
6.11.7.1 N̲e̲t̲w̲o̲r̲k̲ ̲M̲o̲d̲e̲l̲
The Network Modelling Software Package is a mathematical
model of the entire network including submodels for
all types of equipment.
The model is used for consequence calculation of network
topology changes. The model includes the entire backbone
network, the entire terminal access network and the
entire host access network.
Input to the network model is the following data structures:
- The test configuration data base defining the entire
network including terminal access net and host
access net.
- A library of submodels for each type of equipment
(terminal, mux, ICC, node, host). The submodels
are complex queue models which can be updated by
library update procedures.
- Per terminal connected to the network there shall
be defined a traffic profile selected from a predefined
library of traffic profiles. The traffic profile
defines type of traffic, variation within a 24
hour period, traffic volume in terms of number
of transactions and number of input and output
characters per transaction, destination/source
of traffic. The traffic profiles may be updated
by library update procedures.
Initial values for all network parameters may be specified
before a simulation.
A simulation for a specified time-period is performed
by the model and output is produced in forms of a log
data file.
A special data reduction S/W package is provided for
output of log data from the model.
The model is able to provide the following set of data:
- Mean value, standard deviation, and maximum value
over the simulation period of the following parameters:
- Queue lengths for all queues in the model
- Terminal response times
- Line utilization
- The parameter sensitivity to an increase/decrease
of the network throughput is given for each
of the above parameters.
- A histogram over a specified time period of above
parameters may be output.
6.11.8 N̲e̲t̲w̲o̲r̲k̲ ̲T̲e̲s̲t̲i̲n̲g̲ ̲b̲y̲ ̲M̲e̲a̲n̲s̲ ̲o̲f̲ ̲A̲T̲E̲S̲
The "Automated Test & Emulation System" (ATES) is a
general test drive system developed by Christian Rovsing
for the real-life test of major military communication
systems.
The software driving this system may be downline loaded
via the NMH and executed on redundant eqipment in the
nodes, the front-ends or the EMH.
The functional capabilities of the ATES is described
in Appendix F.
The NMH contains all the software necessary for running
a real-life test using the ATES:
- Transaction Volume Generator
- Online Test Controller
- Log File Editor (data reduction program)
6.12 E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Electronic Mail Software Package implements the
protected message switching service for Type B-TDP
traffic and Type B - PMS traffic in the ACDN. These
services can be summarized as follows:
o Direct delivery traffic handling (Type B-TDP)
o Protected Message Switching
- Guaranteed automatic delivery of ATA/IATA messages
and automatic routing
- Longterm storage of messages for retrieval
- Message entry handling
- Message intercept, repair handling
- Logging, journalization, statistics
o Supervision of PMS traffic
- Table Handling
- Delivery Control
- Alarm Supervision
- Storage Maintenance
o Provisions for electronic mail applications
o Adaption to external networks and hosts.
The EMH Services are provided to the following terminals,
hosts and external networks:
Terminals:
- Direct connected teleprinters (TTY)
- Concentrator Switched terminals (CRT's printers).
Hosts:
- RES
- VIA
- SUPPH
External Networks
- SITA
- ARINC
- CNT
- TELEX
The operational specification of these services is
given in section 4.9, and the functional interfaces
against terminals, hosts and external networks are
given in section 6.6, 6.7, 6.9.
6.12.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲E̲M̲H̲
The EMH connects to the network as a general purpose
host. This means tht the transport network services
are used for transport of the messages.
The interface to the terminals is a HAS-Transport net
- TAS connection, although the terminal characteristics
(TTY, CRT, Printer) are mapped on the EMH applications.
The interface to the hosts is a HAS-Transport net -
HAS connection.
The host protocol characteristics are mapped via Host
Protocol Emulators.
The interface to the external networks is provided
by the external Network Access Software (ENAS).
Interfaces to standard peripherals as supervisor VDU's,
discs, line printers tape unit is provided in order
to perform the functions on the EMH.
6.12.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲t̲h̲e̲ ̲E̲M̲H̲
An overview of the EMH S/W package is given in fig.
6.12.2-1.
The EMH S/W package will mainly be based on modifications
of S/W developed for the FIKS and CAMPS projets which
provide services similar to those required for EMH.
The functions of the EMH is distributed on the following
subsystems:
o T̲D̲P̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲T̲D̲P̲)̲
- TDP transfer session setup (HOST-EMH)
- Storage of message
- Enqueuing for printout
- Acknowledgement to Host.
o M̲e̲s̲s̲a̲g̲e̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
- Incoming message analysis (PMS)
ATA/IATA Messages and Telex are accepted
- Address look up
- Incoming message statistics Journalization
- Reporting in case of exceptions
- Release incoming messages for delivery
- Assignment of input serial number
- Acknowledgement to originator
- Enqueuing of distribution and storage
o M̲e̲s̲s̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
- Output of all kinds of messages to printer
devices and to hosts and external networks.
- Output queue handling, delivery according to
priority.
- Outgoing statistics, reporting, journalization
- Message burn in case of burn limit excess
- Assignment of serial output no.
- Output to "drain device" (disc, tape)
o M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲t̲r̲y̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲E̲S̲)̲
- Interactive message entry/message edit
- Interactive retrieval
- Release of entered/retrieval/edited messages.
o M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲D̲S̲)̲
- Distribution according to
1. address list (tx.no)
2. alternate/duplicate delivery
- For distribution to SITA/ARINC:
1. check message length and address
multiplicity (intercept if overrun)
2. Strip addresses already delivered.
- Enqueuing for delivery according to message
priority
- Enqueuing for drain
o S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲S̲R̲S̲)̲
- Storage of accepted messages
- Retrieval catalog
- Retrieval of messages and log/journal
o S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲S̲F̲S̲)̲
- Monitoring (alarms, event logging)
- Control (table handling, device control, storage
control)
- Message Repair functions
o E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲E̲M̲S̲)̲
- Resource Management
- Allocation of queues, discfiles, controlblocks
- Storage/Retrieval
- Access of queues, files, controlblocksd
S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
- Ref. CR80 handbook.
Figure 6.12.2-1
T B D
6.12.2.1 T̲D̲P̲ ̲T̲R̲A̲F̲F̲I̲C̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
The TDP Subsystem handles the tranfer of non-ATA/IATA
messages and non-telex messages (tickets, airway bills
etc.). The transfer session is initiated from the originating
host. The host has to provide the following informations:
- Destination printer address (mandatory)
- Delivery priority level (optional)
- Message burn time (optional)
The message is stored on a TDP message file. This file
is a wrap-around file. Accountability check for delivery
is provided on the file, but no retrieval features
are provided. In case of TDP message non-delivery (no
burn time specified) on wrap-around the message is
copied to a background garbage collection file for
TDP traffic and an alarm is generated to the EMH supervisor.
The TDP message is enqueued to the output device according
to priority. Output is performed by the MOS. The TDP
message stays in the queue until it is delivered to
the output device or burnt. When successfully stored
on disc the message is acknowledged to the originating
host and the session is closed.
6.12.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The MAS handles the analysis and validation of ATA/IATA
messages and telex. Messages entered from terminals,
hosts or external networks are stored on temporary
storage and analyzed by the MAS.
The ATA/IATA messages are syntactically checked as
described in section 6.9.1. The addresses are looked
up and stored on binary form in controlblocks for the
MDS. Telex messages are recognized on the 2 first letters:
'TX'. TX-Number or mne monic addresses are looked up
and stored on binary form as for ATA/IATA messages.
In case of any format error or invalid address the
message is rejected back to the originating terminal
or sent for repair in case of origination from hosts
or external networks.
When checked the message is released for delivery by
the MDS and enqueued for storage by the SRS. Serial
input no. is assigned to the message and acknowledgement
to the originator is returned.
6.12.2.3 M̲e̲s̲s̲a̲g̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The MOS is the server process of all output queues.
For each EMH Subscribing device there is a priority
output queue (6 priority levels are recognized including
the levels of ATA/IATA messages).
The output queues are the only queues of significant
lengths. No hard limits are put on the queue size,
but queue thresholds may be specified by the EMH supervisor.
System queue capacity is only limited by the disc capacity.
The output queues are served in priority order per
device. The messages stay in the queues until the device
is ready to receive.
If a "burn time" is specified (TDP traffic) the message
is burnt, i.e. discarded, in case of burntime excess.
When successfully output the output serial number is
added to the retrieval catalog.
Output to a device depends on the device status. This
status is currently maintained by automatic supervisory
functions and the interactive supervisory function.
The status of a device may be one of the following:
- Device online/offline/failed-open circuit
- Hold traffic
- Alternative/duplicate route specified
- Drain file specified.
Note that MOS serves as well printers as hosts and
external networks.
6.12.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲t̲r̲y̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲E̲S̲)̲
The MES handles the interactive procedures for EMH
users specified in section 4.9.5.2.3 "Message Entry
Handling". The following procedures are supported:
- Enter message (ENT)
- Retrieve Message for hardcopy output (RTR)
- Retrieve for display (RTD)
- Edit message (EDI)
- Release edited message for delivery (REL)
After release/entry of message the message is enqueued
for analysis by the MAS.
6.12.2.5 M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The MDS is responsible for the automatic distribution
of the messages to the output queues.
The distributioon is performed on basis of the binary
addressed looked up by MAS or TDP. Based on the output
addresses the MDS distributes so that:
- the message is enqueued once per output device
- no message is enqueued to the originating printer,
host of external network
- alternate or duplicate delivery is handled
- for delivery to SITA/ARINC the message is checked
for length and address multiplicity.
Furthermore address stripping is performed.
6.12.2.6 S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The SRS is the access subsystem to the long term storage.
Long term storage is provided for at least 8 busy hours
traffic, ref. section 3.5.3. The messages are stored
sequentially and accessed via a retrieval catalog with
the retrieval keys:
- Time, time range
- Originating & destination terminals
- Input serial no.
- Output serial no.
The message file is a wrap-around file. Space for storage
is provided by deletion of old messages corresponding
to 1 busy hour. During deletion it is checked in the
catalog whether the message has been delivered or not
(serial output no. added for each destination). In
case of non-delivery the message is copied to a background
garbage collection file for PMS traffic and a report
is generated to the EMH supervisor. All open queue
references are removed.
As mentioned the retrieval catalog acts as a journal
file which provides for message accountability and
as a checkpoint carrier to be used during recovery
after switchover.
The following events are journalized:
- When the message has been stored
- When the message has been transmitted to an output
device
- When the message is cancelled from a queue
Retrieval takes place using the above specified retrieval
keys. The following keys must at least be specified:
o Time, time range and terminal id
or o Terminal id and input ser.no.
or o Terminal id and output ser.no.
or o a combination of the above keys.
The time used for retrieval will of course depend on
how specific the retrieval keys are. If more than 5
matches are found the operator is requested for more
specific keys - ref. section 4.9.5.2.3.
6.12.2.7 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲
The SFS handles the interactive procedures for EMH
supervisors as specified in section 4.9.5.2.4 "Message
Repair Function" and 4.9.5.3 "EMH Supervisory Functions".
Furthermore the SFS handles the control messages to
and from the NCC automatically. The messages comprises
the following functions:
- On-line table updates
- Device control
- Statistics, reporting
- Delivery control.
6.12.2.8 E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Means for development of electronic mail applications
are provided as specified in section 4.9.5.4 "Electronic
Mail Services".
