top - download
⟦18b3ff896⟧ Wang Wps File
Length: 40812 (0x9f6c)
Types: Wang Wps File
Notes: Techn. Question Response
Names: »1576A «
Derivation
└─⟦121503e5a⟧ Bits:30006255 8" Wang WCS floppy, CR 0116A
└─ ⟦this⟧ »1576A «
WangText
6…08…6…0a…6…0d…6 6…07…5…0a…0…09…0…0c…)…09…)…00……86…1
…02…
…02…
…02…
…02…
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 18
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The proposed network has been configured to ensure
that a single point error will not cause loss of network
service. All critical elements have been made redundant.
Furthermore, the distributed structure of the proposed
nodes ensures that the network is able to provide a
high level of service even in degraded mode of operation
(e.g. where more than one nodal switch processor is
lost). This distribution ensures that only a minority
of users/devices will be affected.
NMH - no effect, as this element is not critical to the functioning
of the network.
NCC - loss of one NCC will not have direct effect on users
(subscribers and applications) as the NCC is backed
up geographically.
The alternative proposed configuration furthermore
provides backed up NCC as the NCC function is integrated
with the Nodal Control Function in the Nodal Control
Processor.
EMH - The backbone network buffers PMS traffic until recovery
has completed. Mirrored PMS file ensures that acknowledged
messages are not lost.
The NCC notifies applications of any PMS recovery to
enable retransmission of outstanding (not acknowledged)
messages.
NCP - (only alternative configuration)
no immediate effect as this function is not critical
to a proper functioning of the node over a short time
span.
Critical when switch-over required of redundant nodal
equipment as when modifications are in process.
NSP - (integrated Communications processor and fep)
Loss of a nodal switch processor (NSP) causes disruption
of all connected sessions while recovery takes place.
All sessions in progress before NSP failure will be
re-established while transactions in process must be
recovered manually from the device by the user re-issuing
the command.
All devices connected to the failed NSP will have an
error message presented to make the user aware of the
fault.
Automatic recovery takes place where protocols protect
the traffic, e.g. the PMS traffic from the EMH.
L̲T̲U̲ - S̲w̲i̲t̲c̲h̲i̲n̲g̲
Only effected devices/users will be disrupted. The
node automatically switches the back-up LTU in-line,
down-line loads the proper protocol firmware and re-initializes
the connection. Manual transacton recovery as above
for NSP.
N̲o̲n̲-̲s̲w̲i̲t̲c̲h̲i̲n̲g̲
Effected devices/users are lost until the faulty LTU
has been replaced on site.
I̲n̲t̲e̲r̲n̲o̲d̲a̲l̲ ̲t̲r̲u̲n̲k̲
No effect on users/applications except slightly degraded
(peak) service by network. Rerouting via alternative
node takes place if queueing delays on trunk group
builds up and exceeds specified threshold.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 60
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document I
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DCN/02 contains replacement pages with the requested
information.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 67
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III, 6.9.6
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) Local reconfigurations refer to the modifications associated
with subscribers (devices) connected to the "local"
node.
b) It takes place as described in our reponse to QID 76.
Coordinated implies that a virtual connection is established
from the site to the NCC.
c) Please refer our response to QID 76 and 79.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 68
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The proposed network is not physically split in more
networks as is the existing (yellow and green).
The split-up caused by a test mode is a logical split,
even though entire network elements (e.g. internodal
trunks, NSPs) may be involved.
Thus, the facilities made available to the field technician
are not limited for physical reasons. The restrictions
posed on the abilities made available are "soft" and
only provided to protect (critical functions of) the
network. Please refer response to QID 79.
a) please refer above
b) the nodal control processor/watchdog of each node provides
a means of remote diagnostics of all major elements
of a node including PUs, CUs, individual modules and
connected peripherals, e.g. disks.
Additional functions similar to existing ACNC may be
made availabile to assist field technicians with diagnostics
of the access network.
The remote diagnostics may take place either from the
NCC facilitating unmanned operation of nodes as well
as locally by using the operator's console of the nodal
CR80 (please refer response to QID 72).
c) please refer (b)
d) please refer response to QID 83.
One of the key elements in ensuring a high level of
security for the network is the capability checks performed
by DAMOS whenever data are accessed.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 70
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
the present implementation in software supports only
entire octets.
The LTU devices, however, have the capability of handling
frames with any number of data bits (no application,
so far, has indicated that software support of this
feature is significant).
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 71
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III, 3.2.1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The impact of the AC ICC network needs special considerations.
It is our belief that common agreements must be achieved
with respect to the trade-offs rerquired for efficiency
versus generality.
Deocumentation reflecting a common approach to the
AC network will be provided as agreed at the meeting
Jan 13, 1982.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 72
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III, pg. 10.35
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The proposed Air Canada Data Network covers the ACNC
functions which are related to equipment and/or services
which are also included in the new network, e.g. the
same level of visibility (or better) with respect to
terminal access network operation, as seen from the
NCC, with respect to looptesting and supervision of:
- Access Network Trunks
- Access Network Concentrators (ICC's)
- Terminals
- Printer (except looptesting)
A summary of the ACNC functions which find their equivalents
in the proposed network is given below:
. Centralized Network Components status Awareness
in NCC
. Interface to Terminal Access Network
. Interface to RES, VIA & DRV hosts
. Interface to ARINC, CNT, SITA
. Interface to low speed network with ASR terminals
to CNT
. Terminals are: CRT's, Printers, FIDS (CRT)
MAC (printer), TRAVICOM (CRT's), ASTC (CRT)
. Concentrators are:
ICC
LCCU (ICC compatibel against ACNC)
ACSI ( do. )
. The "Low speed network" comprises a variety
of inerface disciplines: to CNT to BAS to CP
Air System and transparent terminals currently
supports 8 processor to processor ATA/IATA
links and 6 circuits each supporting about
20 terminals.
The hosts RES VIA will be interfaces via PIU's.
. The Traffic types Control, Type A and Type
B (TDP, teletype ATA/IATA, Telex)
. ICC flow control mechanism. It is suggested
that the handling of these functions be completely
reconsidered with the introduction of SFC's
or even earlier.
. RLMC contention solution mechanism. It is
suggested that the handling of these functions
be completely reconsidered with the inroduction
of SFC's or even earlier.
. Address conversion: LID, PLID etc.
. Type B link handling
. Session Controls including test mode sessions.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 73
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The "Low Speed Network" consists of a number (currently
6) of multidropped teletype lines each supporting approx.
20 terminals. These terminals are supported at the
appropriate nodes.
The software for this is a TAS with the appropriate
network- and link level software modules handling the
multidropped addressing concept used (as opposed to
the ICC interface used against the ICC access network).
In addition hereto, there is a number (6) of ATA/IATA
processor-to-processor interfaces which are attached
to the EMH. They are currently supporting type B traffic
only (if later type A traffic should be accomodated,
such traffic may be core/switched by the EMH directly
from the destination node).
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 75
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) YES dial-up's for unmanned node interconnections
can be accomodated by the NCC.
b) i Internodal trunks must be of X21 type, and X21 automatic
dial up software must be included in LTU, NSS. Commands
for call-up and cleardown must be supported in NCC
(similarly to FIKS).
Other types of call-up (e.g. CCITT V-series) could
be included on request.
ii The remote dial-up was not supported by the proposal
for inernodal trunks.
iii automatic dial-up by NCC of remote resources, for example
based on current Network Hardware (Topology-) status,
and possibly Network load distribution could be supported,
but is not at present.
iv The information needed by the NCC to automatically
dial-up spare trunk capacity, depends on the situations
in which extra trunks are desired, two of which were
mentioned in iii above:
o1 If an existing line fails, and this is reported
(as an equipment error), this could lead the NCC
to autodial for a substitute.
o2 If the network is temporarily highly loaded, extra
trunk capacity could be called in by NCC's auto-dial
facility, thereby improving traffic handling in
a special.
v If dial-up was manual, internodal trunk substution
and/or addition would be supported directly from the
alarms, alerts and notices, in short, the reports which
are generated automatically by the nodes and sent to
the NCC already.
The dialing through to the real time telex network
could, with some delay be handled manually by the NCC,
but this seems clumsy, as opposed to autodialing the
telex from the EMH. The information for autodialing
of trunks would be readily available in the NCC from
the current equipment status data base and the above
mentioned reports to NCC from nodes.
To dial e.g. a telex subscruber the agent must provide,
as part of the call request information, the network
id and the subscruber id, which in turn would be used
by the NCC.
vi Activation of a dial-up is as follows in FIKS.
The operator of the active SCC receives reports on
trunk failures. When he receives one, he can decide
to substitute this failed trunk by a dialed-up trunk.
To do this he enters a commend which specifies identification
of the trunk to be substituted.
The SCC will then, based on this command issue control
messages to the involverd nodes. If one of them is
reached, the autodial function will be issued and this
new topology will be reported back to the SCC.
The operator on a node (if manned as on FIKS) can also
establish a dialed-up trunk to a neighbor node (this
is useful in situation where the SCC has been isolated
from part of the network).
vii Deactivation in the FIKS system is very similar to
activation (but opposite).
c) The points b) vii described the FIKS implementation
of dial-up trunks.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 78
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III, 4.3.6
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The proposed network supports broadcast to the following
groups of terminals:
- all subscribers (teletypes and CRT's)
- only teletypes
- subscribers for which sessions take place with
a specified application
The broadcast message is a special network message
which is transmitted to all nodes, where they are replicated
with one copy in all nodal switch processors (NSPs).
The nodal switch sfotware ensures that only the disginated
subscribers receive a copy.
One copy of the broadcast message is transmitted to
each destination node. This is done at the source.
The load imposed on the backbone network is thus like
that caused by an ordinary message.
However, the access network is loaded substantially
as one copy of the message must be transferred to each
subscriber.
Multiple broadcast messages may exist in the network
concurrently. The design of the broadcast facility
ensures that all designated subscribers receive one
copy of each broadcast message.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 83
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III, 6.10.3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) The complete Network Configuration data base is retained
in the NMH/NCC's.
Three copies are retained in the NMH and the NCCs;
- previous
- current
- under update
The network (NMH/NCCs) ensures that the operator (supervisors)
is constantly working against one data base, the master
copy, which is distributed (on request from NCC or
at demand from NMH) without further intervention from
the operator.
b) The master copy is retained in the NMH and reports
may be generated using preformatted menues.
c) The following elements of the backbone network requires
configuration information:
- Host/Application
. Connectivity set-up
. Protocol
- NMH
. Connectivity set-up
- NCC active
. Connectivity set-up
- NCC stand-by
. Connectivity set-up
- Nodes
. Nodal Control Processor set-up
. Nodal Switch Processor
internodal 'trunk' set-up
access link set-up
Sep connectivity
. Gateway
- Concentrators
. Connectivity set-up
. Protocol
- Subscriber terminals
. Connectivity set-up
. Type
. Classification/access rights
- Users
. Classification/access rights
d) Three copies as described in a).
The limitations are entirely determined by the combination
of the terminal and the user access rights: rights
are the common subset of access right of the teminal
and the uer (rights which are not in both are not granted).
e) An initial configuration exists in each node in order
to enable downlineload of the actual configuration
from the NCC to take place.
f) Devices of the network tables can be accessed both
through their physical address as their associated
logical identifiers.
g) Dynamic changes to the configuration information is
allowed. Changes may be identified as 'Temporary'
or 'Permanent'.
1: Those fields which are not operated by the network
and to which the operator has the proper rights
2: Users with the proper access rights (please refer
d) and response to QID 76/79)
3: The change is validated against the "current" as
the "under update" data base. The "under update"
data base includes the "current" plus permanent
changes.
4: All changes are retained in a mirrored file.
The local nodal versions are under the control
of the NCC. They are retained on (mirrored) disks
and may be regenerated by downlineload from the
NCC in case of a catastrofic nodal disk failure.
5: Yes.
6: Yes - within horizon of one week.
7: Only user directly involved in a change will be
affected (refer QID 76/79).
8: Temporary and timed-out items (automatic deleted)
are removed from the data base.
h) A special command from the NMH supervisor results in
incorporation of "permanent" changes in the "current"
configuration data base and change of status of (old)
"current" to "previous".
i) The regenerated is loaded to the NCC which destributes
the configuration tables to the nodes.
At the nodes the configuration tables are loaded to
the Nodal Switch Processors one at a time. The nodal
control processors throttles traffic destined for the
PU in question while reload takes place. This takes
place in a few second.
j) Synchronization of tables takes place as described
chapter 6.10.3 by means of the CRAM unique version
number.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 86
Date : Jan 8, 1982
Reference: Air Canada Data Network
Proposal Document III,
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Proposed host connection to the UNIVAC 1110
a) Type of link.
The type of link proposed is an ISI channel inerface.
Details of I/F is described in attached document ref:
UNIVAC I/F CR8037D. (CSD/005/PSP/0052).
b) Speed of link.
Bursts of 1 M bytes per second per channel I/F.
c) Protocols supported by the link.
d) Flow control.
e) Terminal addressing.
The protocols supported by the UNIVAC connection deceloped
at CR are the UNIVAC standard protocols as described
in the DCA architecture.
The implementation done covers CMS 7R2A and Telcon
3R1A and will at a later stage cover CMS 1100 and Telcon
4R1.
Consequently, the flow control and the terminal addressing
are as defined in the protocol layers PFC (Port Flow
Control), CSU (Communications System User), INT1 (Interactive
virtual protocol 1), RB1 (Remote Batch 1) and RB2 (Remote
Batch 2).
An interface for the U1110 at YYZ may initially be
based upon a CMS/Telcon implementation, as mentioned
this will give access in a standard manner to TIP,
RSU, and NTR. This implies that the U1110 has to implement
the OS 1110 level 33R or higher. (ref. fig. 3-4).
If some of the functionalities currently done by AIRCAM
are considered required, a TIP-program may be installed
to take care of these special needs. The same program
would be able to link between the network offered by
CR and the existing application programs in the U1110.
A future development of the inerface may include to
install a second special CSU containing cirtual protocol
handlers reflecting the terminal services given by
the network.
f) Link redundancy.
It is possible to connect more than one channel I/F
between a CR80 and a U1110-series host. The CMS-network
definition file will be the tool that solves the problem
of defining the channels within the network of the
host.
The channel handlers of the CR80 may optionally contain
an automatic switching function. This function should
switch from a channel declared down by the software
to one which is not declared down.
Attached documents:
UP-8734...1 p. 3-49
CSD/005/PSP/0052
Recommended documents:
UP-8745-1 CMS-Reference
UP-84649 DCA systems descrip.
SRD No. 416 DMS 7R2A
RIG-424 Telcon 3R1 Inst. Guide
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 87
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) In the CR proposal ACDN/001/PRO/0001 Oct. 8, 1981,
DOCUMENT III, pg. 10.14 was suggested 12 priorities
as follows: 3 for control, 3 for type A, 2 for TDP,
4 for other type B.
This may even be too much; probably seven priorities
will prove sufficient.
b) These priorities are established via the user profile
for some, and via the declared message priority for
other priorities (i.e. the four lowest priorities).
c) The authority to change priorities related to user
profils is with the NCC.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 88
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Any protected message will be recovered from the equipment
that owns it, e.g. the EMH, a Host of possibly an FEP.
The equipment owns a message until an acknowledgement
from the receiver(s) indicate(s) that the message has
been successfully delivered.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 89
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
If the priorities asked for in the RFP and proposed
in the proposal shall be supported, such a distinction
must be maintained also in the host interface.
The most straightforward would be to support at the
host I/F flow control for each individual user under
recognition of priorities or at least by priority and
by application.
However, the existing host interfaces are proposed,
and may later be improved to benefit from the added
network features.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 90
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Host-to-Host sessions can be established by either
Host or they can be permanently established (under
control of NCC).
Depending on the network support S/W in the Host, this
can be a standard Host function (e.g. UNIVAC, IBM)
or it can be done by a special application.
As previously discussed, FEP's might be directly connected
to support host-to-host traffic beyond the bandwidths
possible through the nodal network as presented in
our proposal.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 92
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The gateway checkpointing covers the realtime gateway
status, i.e. ICC emulator status and Network interface
protocols status.
The checkpointing is through the floppy disk of the
nodal control processor (and does not deal with actual
user traffic). Based on this, the sister Gateway component
can recover to the same line interface status (against
ACNC) and the same network interface status (against
packet switching network) as existed before switchover.
All protocols will be in a reset state and user traffic
must be recovered from outside the Gateway, as described
below.
The Gateway does not take responsibility of any protected
traffic, and hence the Gateway shall not checkpoint
and possibly recover any protected (or other) traffic.
Recovery of traffic passing through the Gateway will
be done in other equipment such as: the ACNC, the terminals
(manual recovery, as used on all terminals), the hosts
(e.g. via RES, EMH) or possibly FEP, as previously
described. If certain sessions through the Gateway
are classified as test sessions, this will be retained
also after a switchover since session level checkpoints
are made to disk, so a test environment will not be
lost.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 72
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Refer to diagram shown below
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 81
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) The updating process refers to the activities to bringing
new software into operational use. This is performed
subsequent to a switchover to a backup PU.
b) The network component in question acknowledges the
- reception of an update command
and
- the completion of bringing the software into operation.
The information delivered is
- software version
- status of the network component (e.g. being crated,
in error, in operational use)
Also, refer to section 6.9.12 for an overview of the
NCC network monitoring features.
c) Yes.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 80
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The dump analysis facility will be implemented for
analysis of binary dumps.
The binary dumps may be of the following types:
1) Program-process dumps
2) Dumps of program trace logs
3) Program system tables
4) Application tables
For the types 1,2,3 a wide range of standard S/W maintenance
and trouble shooting utilities will be available. -
The central analysis module will be the:
"Post Mortem Analysis Module" (PMA) - A brief description
will be forwarded to you.
Analysis of the application tables will be included
in the application package.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 84
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) NO, as long as type B traffic only is supported by
these networks, against the EMH, no further sessions
would be required. These networks would be reached
by a message via its network id.
Sessions, however, are required between the EMH and
any user of its facilities.
b) PDN's (when used) provide a transport media, which
is alternate to or in addition to the packetswitching
network in ACDN.
Neither the EMH nor the NMH does care about which transport
media is supporting it.
The NMH services which are in the area of gathering
and structuring administrative planning information,
maintain subscriber files, etc. may use the functions
supplied by the network e.g. protected message switching
as supported by the EMH.
The EMH reports to the NMH as mentioned above, but
does not "use" the NMH services.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 85
Date : Jan 9, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
This is completely dependent of the actual protocol
adapted between each host and the Network. The HAS
will handle on presentation layer a conversion between
the protocol elements actually used by the host and
the virtual protocol used on the network.
A session control application in the host may handle
the establishment of sessions between Applications
and users.
Examples of control messages from Standard IBM and
UNIVAC interfaces could be produced, but they would
have no relation to those needed in the actual configuration.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 91
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Two test modes may be established. One which runs without affecting
live traffic and the other which more corresponds to the present
test mode of the Collins ACNC.
A test network may be set up using the backup NSP of the nodes.
Any LTU or host controller positioned in connected CUs may be
allocated to test mode. This set-up is completely determined
by tables similar to those which apply to the normal network.
This setup ensures that the test network may be a representative
setup of the ACDN network or one where only specific types of
equipment of the network are included.
This test mode uses dedicated resources for establishing the
test network: NSP(s), data channel(s), host controller(s), LTU(s)
(access lines as internodal trunks) and does as such provide
an environment separate from the line.
The single NSP implies an upper limit with respect to the transaction
volume which may be generated in this mode.
A different test mode may be established by using some NSPs
and associated connections for carrying live traffic while the
remaining carry test traffic. This mode is established by means
of configuration tables. In as much as the SBAs are individually
addressable one suprabus may carry live traffic while the other
carries test traffic. This mode does not possess the freedom
of choice which the first test mode has with respect to associating
individual lines (terminations) to the test network. However,
both provides dedicated resources for establishing the mode
operation, isolating live from test traffic.
TECHNICAL QUESTION RESPONSE
QID : 91 (cont'd)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
This proposed test mode setup establishes flexibility to Air
Canada in their selection of test mode subnets, thus, these
networks are essential parts of the configuration tables characterising
the ACDN.
Two subsets are included as part of the proposed system, one
using redundant equipment, and the other applying the alternative.
The impact of adding more than two two proposed test modes is
one of decreasing the disk storage available to other purposes,
e.g. dumps.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 93
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document III, Chapter 4
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a), b) and c) Please refer Chapter 4 and section 6.4 submitted
with DCN/05.
d) Automatic session are basicly seen as a tool for
creation EMH - user connections. The Host/Application
would not be able to see if a session is operator
or manually (read NCC) initiated.
e) When the user's validity expires or if NCC personnel
cancels the connection.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 94
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document III, Section 6.2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Additional description may be found in the CR80 Minicomputer
Handbook 82/83 as part of section 4.10.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 95
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document III, Section 3.4
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The philosophy behind maintaining several versions of the network
data bases are described in Section 3.4.3 and 3.4.4 submitted
with DCN/06 (rev.: Mar 1, 1982).
(Please also refer QID 83 response).
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 96
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document III,
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a and b) A major part of the proposed NCC disks is available
as free disk space. Dumps are treated as ordinary files
and as such protected/available through the DAMOS file
management system.
c and e) Several users may read the same file. Access is however
restricted by the access control list associated with
each file.
The proposed ACDN envisages that only NCC operators
or equivalent have access to these facilities (please
refer QID 79 response).
d) The number of dumps analyzed is limited only by the
number of utility programs active at each connectewd
terminal (a compiled system parameter).
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 98
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document III, 6.9
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Such a feature may be supported by the establishment of a dedicated
TAS/EMH application which could extract the form stock number
returned with the printer Acknowledgement.
Separate sessions will have to be established for providing
this service. Otherwise, they will be supported as other type
B traffic.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 99
Date : Mar 30, 1982
Reference: Air Canada Data Network
Proposal Document III, Chapter 5
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Chapter 3.6.3 illustrates how open ended growth in connectivity
and transaction volume will be achieved.
Expansion must be balanced, i.e. the transactions caused by
addition of e.g. LTUs must be equalled by an increase on processing
power like the one presented by the projected configurations.
Thus, even though the CR80 architecture does support a maximum
of 15 CUs per PU, load restrictions caused by the PU reduces
this. The PU capacity used for sizing is 360,000 peak hour transactions.
Typically, three CUs equipped with ICC-type terminations (LTUs)
may be connected to one NSP.
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 100
Date : Mar 31, 1982
Reference: Air Canada Data Network
Proposal Document I, Chapter 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) DCN/04 to DOC. I, Chapter 1 provides the financial
summary information which reflect baseline and projected
growth both for the three proposed nodes and for the
EMH.
b) The associated system block diagrams are provided with
Part III, chapter 3.6.3 (DCN/06).
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 101
Date : Mar 31, 1982
Reference: Air Canada Data Network
Proposal Document III, Chapter 3.5.3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
a) Christian Rovsing proposes to add to the EMH three
300 Mbytes disk drives each with a formatted capacity
of 256 Mbytes. This corresponds to more than 20 hours
of peak-hour traffic.
It is proposed that the three disks be daisy chained
and each provided with the dual channel option (if
mirrored disks are not a requirement). The mentioned
disk drives uses the same. CR80 disk controller as
the proposed 80 Mbytes disks.
Average seek time: 30 msec
Average latency time: 8.3 msec
Data transfer rate: 1.2 Mbytes/sec
b) This allows a maximum contiguoug storage of about 256
Mbytes to be created.
c) 1985: 3 x 300 SMD's
1991: 7 x 300 SMD's
d) 300 Mbytes per added disk or the equivalent of about
450,000 type B messages.
e) The implication of concatinating disks using daisy
chaining is an improvement of the performance of disk
controller, which supports concurrent seeks on multiple
connected disk drives.
f) The above comment reflect the current technology/available
products.
g) Alternative storage media might be acceptable to Air
Canada. Such a media could be the High Density Digital
Tape Recordings presented in Doc. III, Section 3.8.2
(With DCN/06).
The storage capacity of a HDDT is 3,000 Mbytes or 6,000,000
type B messages (equipvalent of 31 hours of 1991 peak
hour traffic volume).
Q 81060
TECHNICAL QUESTION RESPONSE
Vendor: Christian Rovsing
A/S
QID : 102
Date : Mar 31, 1982
Reference: Air Canada Data Network
Proposal Document III, Chapter 3.5.3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Each PMS transaction results in 1.07 disk accesses (read or
write).
A full track of 32 sectors is moved from the fixed head to the
moveable head portions of the disks. This task takes place as
a background job in order not to influence the EMH external
performance.
Thus, a 15% degradation results from the track transfer from
fixed to moveable head. The resulting bandwidth to disk is:
200 PMS trans/sec.
