top - download
⟦372f014cc⟧ Wang Wps File
Length: 128505 (0x1f5f9)
Types: Wang Wps File
Notes: AIR CANADA PROPOSAL
Names: »2048A «
Derivation
└─⟦4bc3ed402⟧ Bits:30006259 8" Wang WCS floppy, CR 0166A
└─ ⟦this⟧ »2048A «
WangText
…00……00……00……00……00…&…0a……00……00…&…0b…&…0e…&…02…%…0b…%
$…0b…$…01…$…02…#…09…#…0f…#…06…"…0e…" !…0b…!…02…!…05… …0b… …0e… …05……1f……0a……1f……01……1f… …1e……0b……1e……01……1e…
…1d……0a……1d……0c……1d……02……1d… …1c……0a……1c……0c……1c…
…1c……05……1b……0c……1b……00……1b……05……1a……09……1a……0e……1a…
…19……0a……19… …19……06……18……0a……18……86…1 …02… …02… …02… …02…
CHAPTER 2
Page #
DOCUMENT III TECHNICAL PROPOSAL Apr. 29, 1982
LIST OF CONTENTS Page
2. REQUIREMENTS ANALYSIS AND COMPLIANCE STATEMENTS
1
2.1 Introduction
1
2.2 Required Analysis
1
2.2.1 Overall System Requirements
1
2.2.1.1 Backbone Network
2
2.2.1.2 Hosts
3
2.2.1.3 Gateway
3
2.2.1.4 Access Network
3
2.2.1.5 Growth Requirements
4
2.3 Compliance Statements
5
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE :
REQUIREMENT DESCRIPTION:
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
NO
IS CUSTOM DEVELOPMENT REQUIRED? YES NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
2. R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲ ̲A̲N̲D̲ ̲C̲O̲M̲P̲L̲I̲A̲N̲C̲E̲ ̲S̲T̲A̲T̲E̲M̲E̲N̲T̲S̲
2.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The scope of this section is to demonstrate an understanding,
at the strategic and implementation level, of Air Canada's
requirements.
The understanding is made visible in the form of commitments
given to questions in part 8 of the RFQ.
In section 2.2, an analysis of the requirements is
presented. This analysis has two major parts. The first
part is at a conceptual and component level and is
in tune with part 7 of the RFQ. The second part is
at a functional level and is in tune with part 6 of
the RFQ.
In section 2.3, specific answers to questions in part
8 of the RFQ are presented.
2.2 R̲e̲q̲u̲i̲r̲e̲d̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
2.2.1 O̲v̲e̲r̲a̲l̲l̲ ̲S̲y̲s̲t̲e̲m̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The network concept as enunciated in the RFQ is in
line with one major trend in the telecommunication
industry. The trend is that there is a migration of
intelligence or synonymously computing power from the
traditional Data Processing sites to the "Network".
At the second level, the inclusion of host access facilities
and terminal access facilities as part of the concept
network supports the above mentioned trend. It also
provides a unique opportunity to simplify the network
access procedures from the end user's point of view.
The concept of network also represents a structured
approach to solving the problem of migrating from the
existing environment to the common data network environment.
This is seen in the requirement for a gateway. Such
a gateway approach in the context of a generalised,
inter-networking method is utilized for supporting
interfaces to external networks, and solving future
migrationary problems within the IBM and Univac environments.
The requirements for the concept network in the 1986-1991
time frame indicate a need for integrating different
types of traffic originating from a variety of users
and devices. Fulfillment of this need necessitates
primarily:
- a network access procedure that homogenises user
differences and recognises a complex priority scheme;
- a switching architecture that distinguishes traffic
types and responds by dynamically allocating needed
bandwidth and control resources.
The prime concerns mentioned above warrant the use
of a simple data transport technology like DATAGRAMS
with additional end to end stream oriented transport
facilities like virtual connections.
2.2.1.1 B̲a̲c̲k̲b̲o̲n̲e̲ ̲N̲e̲t̲w̲o̲r̲k̲
The backbone network is conceived as a value added
network to be seen in the context of current private
network technology. Provision for services like the
Electronic Mail Network management are interpreted
as value added items in the above context. The generic
elements of the backbone network are seen as:
- Nodes
- Hosts
- Gateways.
The nodes are conceived as high availability pure entities
throughout the network and are required to behave in
an amalgamated manner. The required behaviour of the
node is an amalgam of a network controller, a packet
switch, network management aid, network list centre
and a host/terminal interface unit.
The nodes are networked as a fully connected mesh.
The connectivity is accomplished via high speed (156
kb/ps) inter-nodal trunks. As a switch, the node is
required to switch through 600 packets/second. As an
interface the node is expected to channel attach to
a main frame and behave as an orthodox member of the
main frame determined architecture. As a terminal interface,
the node is expected to support up to 30 access lines
and support interfaces to concentrators, multiplexors
and stand alone terminals.
As a component of the backbone network, the node is
configured as a fully redundant unit with a line switching
subsystem to effect a switchover from a catastrophically
failed active part.
2.2.1.2 H̲o̲s̲t̲s̲
Within the scope of the network are included certain
"Hosts" that provide administrative functions for network
management, electronic mail services.
The conception of network management host based services
coexisting with traditional host based application
services necessitates adherence to OSI principles of
niewing applications in a network context.
2.2.1.3 G̲a̲t̲e̲w̲a̲y̲
Recognition of the need that migration into an independent
data network from the existing network raises the requirement
for a gateway. The gateway approach itself is a principle
tenet of various inter-networking approaches that are
evolving. In the context of coexisting with external
networks such as SITA, ARINC a gateway based on emergency
international standards such as X75 is needed.
2.2.1.4 A̲c̲c̲e̲s̲s̲ ̲N̲e̲t̲w̲o̲r̲k̲
The strategic requirment for the terminal access network
is that future trends in high function terminals, future
trends in DTE standardisation, future trends in main
frame vendors' adoptation of OSI model must be exploited.
Concurrent with the above requirements is a need to
exploit communication cost-saving mechanisms at the
local access level, such as concentrators and multiplexors.
Consequent to meeting the above needs, a formalised
requirement arises for a new store and forward concentrator
with:
- an X25 protocol on access lines connecting store
and forward concentrators to node;
- full duplex to obviate performance constraints;
- speed conversion, code conversion, protocol conversion
to exploit variety of offerings from the market
place;
- configuration requirements of 2.4 kb/ps linking
remote (remote to the concentrator) terminals,
24 terminals per remote line, remote line utilization
of 25%.
The stategic needs for the host access network are:
- freedom to choose a host system based on available
application programs and productivity aids in support
of airline operations;
- an ability to exploit inevitable developments on
price performance of raw computing power.
The above needs give rise to the requirements for:
- standard consistent interfaces;
- an architectural compatibility with major discernible
architectures like: IMB's SNA, Univac's DCA, and
Honeywell's DSA.
2.2.1.5 G̲r̲o̲w̲t̲h̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
In tune with the strategic requirements and in recognition
of the time involved in meeting the strategic requirements,
there is a need for equipment that facilitates an orderly
growth.
The growth is perceived both in terms of increased
number of terminal users and hosts and in terms of
a more than proportionate increase in data traffic.
The sizing of this requirement results in:
- support for a minimum of 8 hosts in 3 centers;
- support for 12000 CRT's and 4500 printers;
- transaction volumes in the range of 540,000-900,000/hr.
The above requirements, coupled with a requirement
for minimum level of performance as perceived by a
terminal user, result in a given set of response time.
2.3 C̲o̲m̲p̲l̲i̲a̲n̲c̲e̲ ̲S̲t̲a̲t̲e̲m̲e̲n̲t̲s̲
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲R̲.̲1̲.̲1̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲T̲y̲p̲e̲ ̲A̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The Datagram Service (DGS) provided by the Network
Switching Software (NSS) og ACDN is ideally suited
to support the Type A traffic. The service provides
a direct interface to the underlying datagram technology
which is used to implement the ACDN. This service is
described in more detail in 6.5.
The structure of the ACDN software is such that load
sharing, to exploit the system resources, can be tailored
by suitable parameterised software packaging. The software
is logically built as "horizontal" layers. Each layer
consists of a number of Tasks performing similar functions.
Now, for optimal functionality, the software is also
partitioned "vertically" into Processes. This results
in parallel Processes (multiserver structure) with
total capability to provide the necessary services
in each node. The operating system provides efficient
means of scheduling and communicating in both the Process
environment and the Task environment.
Thus, load sharing within the node software is total.
As for the internode lines, the primary aim of the
datagram technology is to optimize the transmission
resources by "loadsharing" them between the network
users. The datagram sublayer of the NSS uses a split-routing
technique to spread the outgoing traffic from a node
to the next node on Multiple Link Groups (MLG). Each
MLG consists of a number of Logical Links (LL). The
link level software which controls the LL's again may
share load between multiple physical trunks by using
Multi Link Procedures (MLP).
On the access lines to hosts, the load sharing is achieved
by invoking the relevant Host Access Software (HAS)
functions, such that the incoming traffic is shared
between a specified number of host-applications.
The NSS provides eight levels of priorities. These
levels can be supplemented by invoking Process-priorities
provided by the operating system.
The Type A traffic will be carried through the network
by the datagrams in the ACDN transport system. The
ACDN transport network is functionally isolated and
therefore will not have any bearing on the interface
protocols used to communicate with hosts or terminals.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲R̲.̲ ̲1̲.̲1̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲T̲y̲p̲e̲ ̲B̲ ̲t̲r̲a̲f̲f̲i̲c̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The Type B traffic will be supported by the Virtual
Transport Connection services (VTCS) provided by the
Network Switching Software (NSS) in the ACDN. This
service provides a stream oriented data transport service
with end-to-end guarantee. The service is defined in
more detail in 6.5.
A connection in this context is a logical relationship
between a pair of network users - there does not exist
a unique physical path between these users. This is
due to the underlying datagram technology that is used
to support the service. This means that a connection
servicing a given pair of ACDN users (devices) has
survivability in spite of numerous topological changes
that may occur in the physical linkage of the ACDN.
The actual interface to the ACDN users or devices is
provided by the Host Access Software (HAS) and the
Terminal Access Software (TAS) which reside in ACDN
node. These, in turn, communicate with each other via
the above mentioned connection services.
The Network Switching Software (NSS) will receive requests
for connection establishment from HAS and TAS. A request
will contain the appropriate network addresses. The
responsibility of translating the user or device oriented
addresses to the corresponding ACDN network-addresses
lie with HAS and TAS. For predefined "well-known" users
or devices, this translation may be performed solely
by HAS or TAS. In more dynamic environment of users,
the translation is performed by HAS or TAS in co-ordination
with the Network Control Centre (NCC).
The NSS provides facilities for multiple connection
to the same user or device. The multiple connections
will be resolved as simultaneous user-to-user sessions
in HAS and TAS to provide services that share the same
device. In this sense, HAS and TAS will consider a
particular physical device to house a number of logical
devices, each having the capability of establishing
and maintaining logically independent sessions.
The overhead incurred in sharing devices is limited
to that required for managing and mapping the logical
device structure on to the physical device. The response
times for individual logical-device-sessions will be
affected solely by the strategy employed to map the
responses onto a physical device and not by the internal
communication facilities provided within the ACDN.
The NSS bases the connection services on the end-to-end
protocol employed in its Data Transmission Environment.
The protocol is based on ECMA-72, a standard produced
by the European Computer Manufacturers Association.
This standard is very similar to the one considered
for standardization by International Standards Organization
(ISO).
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : 1̲.̲1̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: T̲y̲p̲e̲ ̲B̲ ̲-̲ ̲A̲s̲s̲u̲r̲e̲d̲ ̲I̲n̲d̲i̲r̲e̲c̲t̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲
̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT: 36 manmonths
(includes entire
EMH)
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
1. The EMH will provide for store and forward message
switching as required.
2. The messages may be retrieved for as long as they reside
on the long term storage. The long term storage is
implemented as wrap-around files sufficiently sized
for 8 hours of peak traffic (200 Mbytes).
3. The EMH has interface to the following terminals, hosts
and external networks:
Terminals:
- Direct connected teleprinters (TTY)
- Concentrator Switched terminals (CRTs, printers)
Hosts:
- RES
- VIA
- SUPPH
External networks:
- SITA
- ARINC
- CNT
- TELEX
4. Messages formatted according to ATA/IATA or Telex formats
will be supported fully including mnemonic addressing
for Telex. ATA/IATA routing indicators from 7 to 11
characters will be supported as specified - including
the special coding for VIA.
5. Functional equivalence of existing PMS services is
provided concerning:
- Device handling
- Delivery control
- Alarm supervision
- Repair function
- Table handling
- Priority delivery
- Retrieval functions
6. The capability limits of the PMS traffic is determined
by the disc size (300 Mbyte) which is sufficient for
8 busy hour traffic. The software is able to handle
up to 600 Mbyte disc devices without any change.
The proposed EMH includes support for normal magnetic
tapes for long term storage.
However, in view of the anticipated large volumes of
type B traffic and limited storage capacity of a normal
magnetic tape alternative means for long term storage
is recommended. - One approach is to use High Density
Digital Tape Recorders which allow for 2750 Mbytes
to be stored on one tape of 14 channels. Christian
Rovsing has implemented a number of archiving systems
using this advanced technology.
7. For each output device (i.e. terminal Host channel,
external network line) there is allocated a priority
output queue of 6 precedence levels including those
of ATA/IATA. No hard limit is put on the queue size,
however a queue threshold may be specified by the supervisor.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲.̲1̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲H̲o̲s̲t̲ ̲t̲o̲ ̲H̲o̲s̲t̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The fundamental view of HOSTS by the ACDN is that they
participate in the network and utilize its transport
facilities to transfer data amongst themselves.
The features that the network has to support bulk data
flow between the hosts are:
- traffic type determination based on the parameters
present during session establishment
- a priority allocation procedure at the session-conversation
level
- a mechanism to gain necessary bandwidth at the
data transmission level by dynamically controlling
the flow control parameters and invoking the facility
for multiplexing one session over multiple virtual
transport and real transport paths
- an operator controlled facility for allocating
necessary resources to particular sessions
When hosts are collocated and are front ended by collocated
dedicated CR80 based front end processors the high
speed interprocessor bus on the CR80 and the supporting
Basic Transport Station facilities can be utilized.
The addressing method utilized in the identification
of end points in a host to host transfer is part of
an overall resource addressing scheme.
The applications at the end points qualify as logical
units under SNA, DCA and DSA.
It is feasible to implement a mainframe vendor independent
file transfer protocol. However, it is not part of
current proposal.
The protocol employed and currently supported is the
HASP for IBM and NTR for Univac with the necessary
cross emulation facilities.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲.̲1̲.̲1̲.̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲N̲e̲w̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲G̲r̲o̲w̲t̲h̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The ability to expand the types of services provided
by the ACDN falls naturally in the overall software
architecture that is proposed.
The layered concepts, on which the architecture is
built, permits changes in the individual layers of
the software without this having repurcusions in the
rest of the software.
An implementation of a Virtual Terminal Protocol (VTP)
will cater for all the future needs of various (different)
types of terminals to communicate with one another.
To exploit the basic communication services provided
in the ACDN, the Virtual Terminal services should provide
services to meet short, transaction type messages and
longer file transfer messages.
Another (parameterized) approach to provide interface
to low speed interactive terminals may be implemented
by following the CCITT Recommendations: X3, X28 and
X29. However, this approach is not as a general as
that provided by a Virtual Terminal approach.
The possible integration of Local Area Networks (Christian
Rovsing X-NET) into ACDN provides an exciting future
prospect of integrating an office automation environment
within the ACDN.
Possible encryption requirements will be met by building
the appropriate algorithms into the Line Termination
Unit firmware.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲R̲ ̲1̲.̲2̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲C̲o̲n̲s̲i̲s̲t̲e̲n̲t̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
This current proposal for ACDN is anchored on architecturally
compatible interfaces to IBM's S̲ystem N̲etwork A̲rchitecture,
Univac's Distributed Communication Architecture (DCA),
and optionally Honeywell's Distributed System Architecture.
Architectural compatibility implies facilities in the
ACDN for emulating architectural entities like System
Services Control point of IBM's SNA, Communication
System User (CSU) of DCA etc.
The required emulators are collected together under
the software package HOST ACCESS SOFTWARE.
Architectural compatibility also implies facilities
in the ACDN for mapping the host's view of resources
to the view of the Network Control Center and vice
versa. This is accomplished in the ACDN by adopting
a definition scheme of virtual and real resources as
described in Doc. III Section 6.7.2.
The level of architectural compatibility has an implication
on the support for IBM, Univac, non IBM, and non Univac
devices.
It is a fundamental aspect of the ACDN design that
SNA devices and DCA devices are supported fully. Non
SNA and non DCA devices pass through an emulator and
get mapped to predetermined SNA appearances.
In the above context the ACDN design does not affect
the efficiency of operation of the hosts or the terminals.
The exploitation of the bandwidth inherent in a mainframe
or to an intelligent terminal must be viewed in the
context of overall bandwidth available in ACDN and
the concurrent connectivity level supported by ACDN.
The level of support for the 43XX mainframe in a SNA
context is considered as a subset of the level of support
provided for in ACDN.
Some customisation needs are foreseen in the IBM channel
interface and PUTZ emulators to support existing terminal
types on AIR CANADA.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲.̲2̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲ ̲E̲x̲i̲s̲t̲i̲n̲g̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Terminals are interfaced to a NODE and supported by
Terminal Access Software. From a definition point of
view and from the point of view of addressing control
and mainframe access path, the terminals belong to
a control area. The control of such terminals, concentrators
and multiplexors is conceived under an overall scheme
External Resource Management. External resource management
has the responsibility for maintaining status information
like device operable, device in error etc. The external
resource manager has the responsibility for informing
the NCC. Thus the ICC site status is kept track of
together with associated link status.
Architectures like SNA and DCA support single user
multi host sessions and provide for session passing
between hosts. The ACDN facilities support session
passing. Printers come under certain logical unit types
and certain function management profile. With customisation
on existing facilities, multihost access to printers
will be supported.
With reference to Part 7 ch 3 3.1 (I)
- PC issue is supported by the terminal access software
(TAS)
- Sign in are at the nearest node and service data
to support signins are maintained at node NCP mass
storage
- Statistics are collected at node but maintained
at central network control and management site
- All physical status information/recognition and
unit recognition take place at the node (TAS) and
are communicated to NCC when necessary
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲R̲.̲ ̲1̲.̲2̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲N̲e̲w̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
There are three basic aspects of the proposed approach
to ACDN that facilitates interfacing new terminal types.
- At presentation level a virtual terminal facility
and a bulk data file transfer facility are provided
for.
- At transport level transparent traffic facility
is provided for.
- At the terminal interface level (via a LTU) specific
sets of terminal support handlers can be loaded
from a control point.
- At a product level the existing node configurations
can be expanded to include local area networking
capacilities via the X-NET.
The above facilities provide AIR CANADA with freedom
in selecting future terminal equipment, a freedom which
aims at a capability to incorporate and support new
terminal facilities as they evolve.
It is emphasised that a standard Virtual terminal protocol
or a standard file transfer protocol does not exist
at present. INT 1 supported by Univac and IBM PU-TZ
protocols by IBM are treated as "standardization" based
on current protocols.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲.̲ ̲1̲.̲2̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲I̲I̲ ̲6̲.̲8̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The interconnection to the external network will be
installed at the NSP's, i.e. each external network
will be interfaced to the most appropriate node with
respect to topology.
The lower level protocols will be implemented in peripheral
processors, LTU, to meet the requirements of the individual
connection. The intermediate levels will be implemented
in the NSP whereas the highest levels will reside in
the EMH. This distribution philosophy will ensure that
the network equipment will not introduce any limitations
on the interconnection interfaces.
The present time speeds and the protocol limitations
inherent in the external interfaces will define the
efficiency attainable.
CR plans to assign the following LTUs for the initial
interconnections.
2 LTU ARINC 2 x 2400 bps (B type
only)
2 LTU CNT AES weathers 2 x 150 bps
Airline Switching 3 x 150 bps
1 LTU CP Air / BA 2 x 150 bps
1 LTU SITA (new) 1 x 2400 bps
1 LTU Low speed network 4 x 150 bps
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲1̲.̲2̲.̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲M̲e̲d̲i̲a̲ ̲C̲o̲m̲p̲a̲t̲i̲b̲i̲l̲i̲t̲y̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The proposed ACDN provides possibilities of exploiting
a variety of data transmission facilities. This statement
is based on the fact that interfaces to such low level
facilities are isolated in the peripheral Line Termination
Units (LTU). These LTUs are firmware controlled. The
firmware can be downline loaded from the local node
or a remote node. Vital parameters affecting the performance
of the firmware are setable from the CR80 computer.
Features like automatic dial-up, automatic baud rate
selection and automatic protocol detection can be implemented
in the firmware to provide enhanced services.
Circuit switched digital lines may be incorporated
instead of or to complement the use of leased lines.
Satellite links can be provided by using the CCITT
Recommendation X75 with extended formats and implementing
selective reject procedures whereby only specified
corrupted frames are retransmitted.
An alternative satellite protocol that may be used
is the LIT ̲SYNC protocol developed by LITTON for use
in the NICS-TARE network, which forms the backbone
network for NATO communications. Christian Rovsing
has first-hand experience in the implementation of
this protocol and uses it in current implementations
of military networks.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲1̲.̲3̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: O̲p̲e̲n̲ ̲e̲n̲d̲e̲d̲ ̲g̲r̲o̲w̲t̲h̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The response to this requirement is by necessity covered
in many different parts. However, the highlights of
the approach are
- the hardware architecture together with coherent
multiprocessor support ensures growth in a simple
modular fashion
- the software structure in a layered way permits
-- local and remote hosts
-- distributed control functions
-- geographically backed up centres
-- an addressing scheme with the following limitations:
Calls: 54000 simultaneous subscribers per mode
(3,000 simultaneous CRT subscribers per NSP)
Session: Up to 7,500 per NSP
Connectability: Up to 22 ICC-type, 44 X.25 type per
CU
Addressing: Up to 255 regions
Up to 255 S-NODES/region
Up to 16 ̲ S-NETs/S-NODE
Up to 256 LTUs per PU
Up to 64 lines per CU
Throughput: 200 packets/sec. per PU
Design throughput: 100 inquiries/responses per sec
per NSP…86…1 …02… …02… …02… …02…
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲1̲.̲3̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: I̲n̲i̲t̲i̲a̲l̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The proposed equipment configurations have been sized
to handle the traffic volume and addressing capacity
which reflect the RFP, year and 1985 requirements.
(for further detail please refer chapter 3, section
3.6).
a. Hosts.
Each NSP of a node may support one or more host
interfaces. However, the upper limit is determined
by the traffic volume with apply to the connection
and not by limitations of the hardware.
b. Terminals
The initial baseline system supports more than
the required 12000 CRT terminals and 4.500 printers.
c. Sessions
The proposed baseline system supports an average
of two sessions per CRT terminal and one session
for other types of devices
d. Transmission Volume.
The proposed baseline system has been sized to
handle the end 1935 traffic and transaction volumes
for all lists.
e. High Volume Host Interface
The host interfaces proposed operates at data channel
speed.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲1̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The network provides short term resilience (minutes
or seconds) by
- employment of datagrams which adds automatic rerouting
as prt of routing algorithm in case of node failure
- distributed buffering capacity in each switching
element which allows transactions to be retained
for seconds or minutes until the situation has
normalized
Flexibility to handle long term variations will in
particular be ensured by the modular structure of the
embedded CR80 computer which enables a high level of
tailoring to specific needs. For example, minor reconfigurations
are envisaged to take place during the 86 - 91 period
where extension elements similar to the equipment proposed
are integrated in the nodal equipment.
These modifications do not require software structural
revisions. Inclusion of new software/firmware is normally
performed online, while configuration changes anly
need table updates.
The use of general virtual protocols within the Air
Canada Data Network allows mapping in the 'Terminal
Access Software "(TAS) and the "Host Access Software"
(HAS) on inclusion of new terminal respectively Host
types.…86…1 …02… …02… …02… …02…
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲1̲.̲5̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲-̲r̲e̲s̲p̲o̲n̲s̲e̲ ̲-̲t̲i̲m̲e̲ ̲-̲ ̲T̲y̲p̲e̲ ̲A̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The response time for ltype A transaction is shown
in section 3.5.1.1 (chapter 3, page 58) to be
85% - 1.7 sec
95% - 2.7 sec.
However, it should be noted that if the Terminal Access
Network (ICC type connections) is excluded the following
is devised
85% - .2 sec.
95% - .5 sec.
The Datagram Service (DGS) provided by the Network
Switching Software (NSS) of ACDN is ideally suited
to support the type A traffic, with its tight requirements
to response time. The DGS will use split routing in
order to spread the traffic between two nodes and optimize
the usage of the total bandwidth available between
any two nodes.
A multilink protocol is implemented in the network
and it will disperse datagrams over the physical links
on a pseudo probabilistic basis.
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 is a group of trunks.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲1̲.̲5̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲ ̲-̲ ̲H̲i̲g̲h̲ ̲P̲r̲i̲o̲r̲i̲t̲y̲ ̲P̲r̲i̲n̲t̲e̲r̲
̲T̲r̲a̲f̲f̲i̲c̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The response time for this type of traffic is shown
in section 3.5.1.1 (Chapter 3 page 58) to be less than
5 seconds for more than 9.5% of all transactions.
The plain backbone delay is shown to be less than .5
sec. for 95% of all transactions. The majority of
the delay is caused by the terminal access network.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲.̲ ̲1̲.̲5̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲ ̲-̲ ̲T̲y̲p̲e̲ ̲B̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The response time for this type of traffic is shown
in section 3.5.1.1 (chapter 3 page 58) to be less than
5% for more than 95% of all transactions of this type.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲1̲.̲5̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲ ̲C̲o̲n̲s̲i̲s̲t̲e̲n̲c̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The proposed network provides the user with consistent
response times as shown by the fractile summaries presented
as part of section 3.5.1.1 (chapter 3, page 58).
The major contributor to the response time variations
stems from the outgoing queues for the terminal access
network.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲1̲.̲5̲.̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲ ̲L̲o̲c̲a̲t̲i̲o̲n̲ ̲I̲n̲s̲e̲n̲s̲i̲t̲i̲v̲i̲t̲y̲
̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The response time will be location insensitive seen
from the users point of view. This is devised from
the fact, that normal mode of operation, transactions
traverses the network on at most one internodal trunk.
SEcondly, the internodal trunk speed selected, 56
kbps, results in an internodal trunk queuing and transfer
time on a fraction of the queuing and transfer time
experiensed in the ICC terminal access network.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲1̲.̲5̲.̲6̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲S̲e̲l̲e̲c̲t̲i̲v̲e̲ ̲F̲l̲o̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲/̲P̲r̲i̲o̲r̲i̲t̲y̲
̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The priority structure comprises eight discrete values
from 0 through 7. This is accomodated by a 3 bit priority
field in the datagram header which could be changed
in the future. A datagram format identifier DFI is
provided to differentiate between different formats.
The priority servicing algorithm will work in this
way:
1. Messages of highest priority will be given a certain
bandwidth so that they will always be taken into
and routed through the network even during congestion.
The amount of such messages must be guaranteed
not to exceed this bandwidth.
2. Traffic control will give messages on their way
out of the network (because they have reached their
destination) a higher priority than relay messages.
3. Traffic control will give delay messages a higher
priority than messages on their way into the network
(messages which have just been released).
4. Relay messages will be processed according to their
individual priority. This is done by dividing each
Trunk Queue into a number of sub-queues, one per
priority level. A relay message is put into the
sub-queue which corresponds to its own priority
level. The sub-queues are served from the high
through the low level.
5. Messages entering the network will be processed
according to their individual priorities. This
is done, in a way similar to that mentioned in
4, by dividing the Transport Queue (which is the
input queue to the network) into sub-queues: one
per priority level.
The priority of messages may be adjusted.
The selective flow control mechanisms in the ACDN will
automatically cope with any traffic congestion in normal
and degraded mode. A scheme has been implemented in
the NSS which will prioritize the sequence of discarding
overloading traffic.
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 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 improve the transit traffic.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE :\ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲1̲.̲5̲.̲7̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲N̲e̲w̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The flow control and priority facilities, which are
part of the proposed ACDN network, facilitates new
implementation services without affecting the type
A traffic performance.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : 1̲.̲6̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲ ̲S̲t̲a̲n̲d̲a̲r̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED?
NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT:
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
o Reliability calculations show that an End User
one time per 5 years will be unable to access a
given host for a period of 30 min. (Mean).
o Software and configuration changes will not because
of the use of standby components cause outtage
of the nodes.
o The use of standby components means, that in connection
with the use of watch dogs which automatically
switch the standby component in in case of failure
of an active component, that recovery time from
failure can be held below 1 minute.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : 1̲.̲6̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: S̲i̲n̲g̲l̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲ ̲F̲a̲i̲l̲u̲r̲e̲ ̲S̲u̲r̲v̲i̲v̲a̲l̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED?
NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT:
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
o As a key concept in the proposed systems all essential
components, Node, EMP & NCC processing units (PU)
are backed up with standby PUs which automatically
are switched in by the Watch Dog in case of error
in an active component.
o Survival of Trunk failures are handled by alternative
routing in the network.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲R̲ ̲2̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: R̲e̲m̲o̲t̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲t̲o̲ ̲B̲a̲c̲k̲ ̲u̲p̲ ̲H̲o̲s̲t̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The rerouting strategy which apply to back-up hosts
is the responsibility of Air Canada. The Data Network
should not influence this strategy. However, once
this strategy has been decided upon, the network will
be able to provice the required rerouting between hosts
of similar type (seen from network).
- Host failures are treated under the general scheme
for external resource failure. In the context
of the proposed ACDN an ICC failure and a host
failure are similar since they have the effect
of a SUBAREA being lost.
- The existing software facilities do not provide
for a̲u̲t̲o̲m̲a̲t̲i̲c̲ switchover to the back up host.
The operator can initiate such switchover.
- IF AIR CANADA designates permanent back up hosts
and assigns the necessary LU for NCC to initiate
recovery action, then the switchover can be made
automatic. The basis behind the above assertion
is that all LU-LU sessions are monitored by MCC.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲R̲ ̲2̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: S̲i̲g̲n̲-̲i̲n̲ ̲D̲u̲r̲i̲n̲g̲ ̲C̲o̲n̲g̲e̲s̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
With the existing software priority scheme at user
log on time are not considered as inherent network
function.
Application priorities can be incorporated in the TAS
context and in the HAS context.
The proposal commits to incorporate specific AIR CANADA
priority schemes at user access level.
Any user (operator at his terminal or host application)
is always able to get a priority message through to
the system operators, who ultimately must be responsible
for proper allocations of priority assignments within
the network.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲2̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: M̲u̲l̲t̲i̲ ̲S̲i̲g̲n̲-̲i̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The primary philosophy that users sign in to applications
rather than host is supported by existing software.
Each host is a subarea with applications as major
node and a group of LUs assigned to them.
However, the current software does not support a host
select facility for transaction processing implying
multiple applications keeping active sessions. The
required extensions to existing software are committed
for in the proposal: the presently used host selection
profix is proposed employed to establish the required
multiple host sign-in (For further detail please refer
section 4.12.1 - chapter 4 page 97).
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲R̲ ̲2̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲E̲q̲u̲i̲v̲a̲l̲e̲n̲t̲ ̲F̲e̲a̲t̲u̲r̲e̲s̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT N/A.
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Generally the proposed system provides replacement
and enhancement of the operator functions and user
facilities of the existing network. The enhancements
are done on the basis that the ACDN is an independent
entity and hosts provide services to the users of the
ACDN.
The functional equivalence will appear from the following
references to section III 4 and III 6 of the technical
proposal.
F̲u̲n̲c̲t̲i̲o̲n̲ ̲A̲r̲e̲a̲ R̲e̲f̲e̲r̲e̲n̲c̲e̲
Session Control III 4.12.1
Routing Control III 4.9.5.2
III 6.5
Host Terminal Terminal and Host
Presentation Characteristics are
mapped by the HAS
and TAS, ref. III
6.6. & 6.7 ff.
Network Management
and Control III 4.6, 4.7 and 4.8
Backup Facilities III 4.11
Degraded Mode Operation Provided by the inherent
priority structure
of the system
Testing and Split System Refer to response
to req. 3.15
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲.̲ ̲2̲.̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: G̲u̲a̲r̲a̲n̲t̲e̲e̲d̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT:
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The proposed transport system and the associated end
to end protocol provides for guaranteed message delivery
from source to destination transport station level.
The link access protocol from the destination TAS to
the destination terminal provides for normal error
recovery.
In cases where the destination is not immediately available,
the TDP service offered by the EMH may be used. Here,
however, the EMH will take the responsibility for guaranteed
delivery. This means that the message is acknowledged
when it has been safely delivered to the EMH. The
service of getting positive acknowledgement to the
originator when the message is delivered may easily
be added as an EMH application. .This service may be
provided by letting the originating application specify
the acknowledgement request as a parameter in the session
setup command.
The message control block in the EMH may then be marked
correspondingly and the service could be added as part
of the message output subsystem of the EMH.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : 2̲.̲6̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: S̲e̲c̲u̲r̲i̲t̲y̲ ̲-̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲c̲c̲e̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT: 6 manmonths
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
A sign-on security system similar to those of existing
military networks will be provided centrally in the
NCC.
A user signing on will have to identify himself with
an indentification code and a password. Each user
will then have access to a number of specified terminals
and a number of specified services. This information
is stored centrally in the user security profile. This
profile is matched against
- the entered user-id
- the entered password
- the terminal profile of the used terminal
- the sign-in service identification
Thus, all session establishments requiring security
access control will have to use the centralized NCC
Network Access Service as described in section 4.5.3.
Security for data access from an application is provided
by an authentication procedure. The calling application
shall return a random generated password forwarded
to the application by the Network Access Service via
a separate set up session after the application service
access profile has been matched against the session
establishment record.
Public network access is supported by the DTE functionality
in the nodes. The required port address translation
to the ACDN network address is accomplished at the
node. The access validation procedure is common to
all ACDN users and is controlled by the NCC.
The terminal-to-host access security system uses access
profilers at the NCC for validation. This profile information
can be accepted on a per call basis by the nodes via
the user data field in the call request packet and
can be analysed for access validation by the NCC and
the node.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲.̲ ̲2̲.̲7̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: S̲e̲c̲u̲r̲i̲t̲y̲ ̲-̲ ̲T̲e̲s̲t̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED?
NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT:
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Test environment security is accomplished by assignment
of a test subscriber with users having private access
to test terminals and test services. Thus the isolation
of test equipment is accomplished by the generation
of a coherent set of test subscriber user security
profiles, test terminal profile, installation of a
test host with test services.
The above facilities are backed up by inherent partitioning
features of the CR80 and DAMOS.
It is feasible to create secure software partitioning
within the NMH to isolate the test environment.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲2̲.̲8̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
Bit-oriented Protocol
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The present implementation supports entire octets.
The LTU devices, however, have a capability of handling
frames with any number of data bits (no application,
yet, has indicated that software support of this feature
is significant).
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲2̲.̲9̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲E̲n̲c̲r̲y̲p̲t̲e̲d̲ ̲D̲a̲t̲a̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲y̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES/NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Encryption may be used in the following locations:
o On internodal trunks (continuous on-line encryption).
This prevents tapping our trunks directly, and
is highly secure.
o On specified packets (bulk encryption). This prevents
reading of data from selected users.
The clear data from such terminals should be kept separate,
i.e. the best would be to bulk encrypt data directly
at the terminals, subsidiarily in the adjacent node,
but then the terminal access network trunk carrying
traffic from such terminals must also be on-line encrypted:
It it is only a limited amount of traffic which should
be secured: bulk encryption with forward key select
on the individual terminals would be preferable.
Ideally the terminal itself would do the encryption/decryption.
This would require an encrypting and a normal version
of the terminal. Another way which could be used at
least initially is to let the bulk encryption/decryption
be carried out by a box attached on the cable between
the terminal and the multiplexer in the ICC network.
In both cases forward key select could be used, and
several forms of correspondance between sender and
receiver are possible.
One way is to randomly select between secret (externally
loaded) keys. The receiver will accept and decrypt
on any forwarded key selector. This lets any number
of boxes communicate mutually.
More restrictively, the received can be set to accept
only one or a few key selector values, and reject all
others. In this case there must be at least as many
keys and key selectors as there are receivers, i.e.
crypto boxes.
R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲
The response time is only affected negligibly by on-line
encryption on internodal or ICC network trunks.
Bulk encryption tends to create a delay corresponding
to the transmission time of the bulk. However, in the
case where a crypto box is located in the immediate
vicinity of the terminal, to which it is attached,
the transmission speed between the box and the terminal
could be increased up to 19.2 K bps, in which case
extra delay introduced is in the order of
300 x 8 bits/transaction
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ = 125 MS
19.2 K bps
The security of the encrypted data is highest in the
distributed encrypto nodel, where encryption is done
in or close to the terminal, but is of course also
highly dependant on the crypto algorithm used, and
on whether this algorithm and the keys used with it
can be assumed to be secret themselves, or public.
A way of expressing the degree of data security is
by the probability that a hostile party will have broken
the code by a certain time interval. Exact figures
cannot be given unless the specific encryption model
is determined.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲R̲ ̲2̲.̲1̲0̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Response to related questions in RFP, part 8, chapter
1:
- Extensive error detection and recovery facilities
are provided within network protocols and these
are supported by the error detection facilities
at hardware and connection interfaces level.
- Protocol overheads are mainly influenced by the
standards adopted.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲2̲.̲1̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: V̲i̲r̲t̲u̲a̲l̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
It is proposed to implement the ECMAs Virtual Terminal
Protocol as part of the ACDN.
This virtual protocol enables Air Canada a mapping
of new equipment. In fact, new equipment could be
designed to work directly with the virtual protocols
in the network. By providing a baseline for future
communication via the network, the virtual protocols
are vehicle for commonality in the ACDN.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲R̲ ̲ ̲3̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲S̲t̲a̲t̲u̲s̲ ̲A̲w̲a̲r̲e̲n̲e̲s̲s̲ ̲-̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲M̲o̲n̲i̲t̲o̲r̲
̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Device status awareness for all ACDN device attachments
is obtained through the STATUS-TERM (DEVICE) command
facility available to NCC operators, technicians, and
users (limited display).
A network operator report similar to the present ACNC
command GRT (respons-time report) will be available
(see section 4.8.9).
Terminal user reports similar to the present ACNC reports
DNE (network error report) and PDS (printer display
status) will be available (see section 4.12).
STATUS-TERM
Produces a status display showing all relevant status
for the specified terminal.
This command function may be used for displaying the
connection status of all the various types of ACDN
devices, CRT's, printers and FIDS, etc. The status
indication will include, but is not limited to, the
following:
o sign-in status (free, in session)
o terminal condition status (included/excluded,
operable/in error)
o status of physical and logical paths to destination
(multiplexer, remote lines, concentrator including
concentrator components, concentrator lines, nodes
and node components, inter nodal trunks)
o routing status - primary or alternate routing on
access network, routing through backbone network
to host/application.
These status indications will be available to network
supervisor and technicians accessing the network from
an NCC supervisor or engineering position, or from
an ordinary user terminal attachment. The status information
will be retrieved from the global NCC device status
tables, which are recoverable in the event of NCC failure.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲R̲ ̲3̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲S̲t̲a̲t̲u̲s̲ ̲a̲w̲a̲r̲e̲n̲e̲s̲s̲ ̲-̲ ̲U̲s̲e̲r̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
User status awareness for all ACDN users will be satisfied
through status request/response functions in which
either a specific device may be indicated - or the
originating user terminal is defaulted. This means
that a user can request his own status, and a field
technician may obtain status indications for any device
within ACDN, displayed at a user terminal at which
he has logged in.
The following user status awareness facilities are
provided (these are all described in section 4.12.2)
o connection-status
o display-network-errors
o display-TDP-status
Further, Broadcast is provided as described in section
4.8.11.2.
U̲s̲e̲r̲ ̲S̲t̲a̲t̲u̲s̲ ̲A̲w̲a̲r̲e̲n̲e̲s̲s̲
Terminal users will be able to request their actual
connection status concerning the terminal and printer
condition and the active user sessions.
Further, for the purpose of fault isolation and verification
a number of report display functions are available
to users/technicians at an ordinary user terminal.
The status request functions will display the status
of any specified ACDN terminal at the originating terminal
position.
Commands:
CONNECTION-STATUS term ̲id
This command is prompted by a response indicating the
following status information for the specified terminal
(if term ̲id is omitted, the used terminal is assumed):
- sign-in status (number of parallel sessions, session-ids,
names of connected applications, sign-in elapse
times)
- terminal condition status
- printer status condition
- status of physical and logical paths to destination
(multiplexer, remote lines, concentrator including
concentrator components, concentrator lines, nodes
and node components, inter nodal trunks)
- routing status - primary or alternate routing on
access network, routing through backbone network
to host/application.
DISPLAY-NETWORK-ERRORS (parameters)
Several response reports may result as controlled through
parameterized options:
The first type of report that can be generated displays
transactions and errors for each of the multiplexors
attached to a specified remote controller on the concentrator
(ICC).
A further interrogation can be made by adding the multiplexor
number in the command. The report will then list errors
for each terminal device controlled by the specified
multiplexor.
B̲r̲o̲a̲d̲c̲a̲s̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲a̲c̲i̲l̲i̲t̲y̲
The broadcast message command allows a message of up
to 22 lines to be sent to a specified CRT, to a range
or all CRT sets and/or all teletype terminals. Broadcast
messages are used when all or certain locations must
be advised of a planned function or system shutdown,
local operating conditions, etc.
The message remains active in the system for the time
specified, or until it has been delivered to all the
desired terminals. For a terminal which has a broadcast
message outstanding, an info-indication is appended
to all output to the terminal, prompting the user to
solicit the broadcast message is solicited and sent
to the terminal. To solicit the message the user depresses
the ENTER key on the CRT.
A CRT can solicit a given broadcast message only once,
and therefore the info-indicator is not appended once
the broadcast message has been delivered to the terminal.
Broadcast messages to teletype terminals are sent as
normal teletype messages. These teletype messages will
be created and processed as normal protected traffic.
Broadcast messages can be sent to the various terminal
categories indicated in the following list:
Commands:
BROADCAST time ALL
A message is sent to all CRTs. Time is the number of
minutes the message is to remain active in system.
A message is ready to be transmitted to every configured
CRT on the network.
BROADCAST time Nxxxxxxx…0f…1…0e… Nxxxxxx…0f…2…0e…
A message is sent to a range of CRTs. N = Network xxxxxx…0f…1,2…0e…
are the logical id's of the first and last terminal
within the range. A message is ready to be transmitted
to the terminals identified by the id range.
BROADCAST time Nxxxxxx
A message is sent to a specific CRT. Only the terminal
named in the command may solicit the message.
BROADCAST time all TTY
A message is sent to all CRTs and to all Teletype Terminals
BROADCAST time TTY
A message is sent only to all Teletype Terminals
BROADCAST time APP (RES, DRV, PMS or VIA)
A message is sent to all terminals signed in to a specific
Host/application.
A finer breakdown can be displayed by identifying the
terminal in the request.
The following status indications are included in the
display per ICC/MUX and terminal:
- input errors
- output errors
- total errors
- error percentage
- total traffic
DISPLAY-TDP-STATUS device-id
The current status of the specified TDP printer is
displayed, including
- device status
- configuration information
- error statistics
- message queue length
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲3̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲A̲l̲a̲r̲m̲s̲ ̲a̲n̲d̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT Included in
NCC integration
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The alarms/statistics to be provided in the network
are listed in detail in the following sections:
1. NCC Alarms: Section 4.8.6.1
2. Statistics: Table 4.11.1-1
3. EMH Alarms: Section 4.9.5.3.3
The reports generated periodically or on request based
on the statistical results are given in detail in section
4.11.2 ff.
- The statistics are generally implemented as counters
to be reset once per 24 hour period.
- The listed statistics are all compiled at the nodes
or at the EMH. Both places the statistics are stored
on mirrored disc, which means that full recovery
is provided for all statistics.
The incore memory claim on the nodes is estimated to
be 10 words per terminal (20 bytes) plus 10 words per
terminal of general work area (processing and disc
buffer capacity). In total 60K words of incore statistical
counters and buffers are needed per PU, assuming 3000
terminals per PU.
The disc resident part will be less than 2 M bytes
per node.
Generally the processing time associated with statistics
is negligible (less than 1%) compared to node switching
functions.
The session and terminal dependant statistics are so
dominating that all other statistics can be considered
negligible.
The session and terminal statistics are estimated to
be:
- 20 bytes per terminal per hour
- 40 bytes per session
Assuming 20000 terminals and 2 sessions per terminal
per hour, the statistical data transfer is:
20000 x (20 + 2 x 40) bytes = 2 M bytes / hour
This equals 555 bytes per second or about 2 packets.
This may be compared to the PU switching capacity of
200 packets per second.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲R̲ ̲3̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
REQUIREMENT DESCRIPTION: C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The Network Definition Application program is a flexible
easy to use definition tool for settling up complete,
consistent overall ACDN definitions as described below.
N̲e̲t̲w̲o̲r̲k̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The global network definition table resides globally
at, the NCC. Basically, the same Network Definition
application as mentioned in 4.2.1.1 (NMH) will be available.
The definition application will run as a low priority
job without affecting network supervision services.
Three different definition files are maintained:
- old network definition
- current network definition
- under update network definition
The definition file specifies all network components
including transport network and external resource network
(hosts, concentrators, and terminals).
The interactive Network Definition application outputs
a new network definition table in the "under-update"
definition file
The current network definition file contains a copy
of the online network table. In case of catastrophic
failures occuring when using a new network definition
file, the NCC may reinitialize the network according
to the previous configuration (old). Minor errors
in the online network definition may be corrected through
resource control commands and/or online table update.
N̲e̲t̲w̲o̲r̲k̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The network must be defined both globally, i.e., the
complete actual configuration, and locally to each
host.
The global ACDN definition is a hierarchy which defines
both the external resources (participants and attachment)
and the internal resources, e.g. internodal and access
links.
The definition is grouped as follows:
Transport System
nodes (node-id)
link (link-id, LTU-addr.)
Virtual circuit capacity
links (link-id)
connection
speed
transport station (TS-id)
sub-transport station (DTE-addr.)
External Resource Type
host types
line types
controller types
terminal types
line group, main type (LTU-addr.)
line, sub-type (line-id)
controller (controller-id, poll-addr.)
terminal (term-id, local addr.)
NODE Configuration (NODE-id)
channel (channel-id, channel-I/F addr.)
host (host-id)
line (line-id, LTU-addr)
host or communication controller (host-id)
external resource (resource-id)
The definition is performed on-line at the NCC or off-line
at the NMH via an application which via suitable forms,
allows the operator to fill in the necessary parameters.
The defined network configuration is stored in object
files from which they can be later loaded during initialization,
recovery or dynamic reconfiguration.
Commands:
DEFINE ̲NET (in-definition-file)
(out-definition-file)
This command starts the network definition application
which via a menu, selects the forms to be filled in
or changed.
If in-definition-file is specified, an existing definition
is used as starting point.
Out-definition-file is, if specified, used to store
the new definition.
Apart from the form editing facilities, DEFINE-NET
is able to merge and split definition files. It also
contains a print utility for easy and legible forms
print out.
The definition of the networks seen by the hosts are
done at the hosts. These definitions must use the same
names as ACDN to identify each external resources.
To allow ACDN to perform address translation between
ACDN and host network addresses, a resource name-address
table must be existing prior to network initialization.
The network definition program will provide fill-in
formats and as far as possible guide the user through
the configuration process, the goal being that a complete
definition of a consistent network should not be a
time consuming job.
The configuration definition formats and the network
table is constructed in a hierarchical manner, and
with provisions for storing any equipment characteristics
that can be thought of today, this does not present
inclusion of new equipment types.
To assist supervisory and management staff in maintaining
network definitions, the definition application can
produce hierarchical, easy to read, network definition
report printouts, identifying topologies and component
characteristics.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲3̲.̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
REQUIREMENT DESCRIPTION: C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Network configuration and service data information
will be distribited on major network components as
follows (also see section 6.4):
N̲C̲C̲
The NCC will contain the master copy of all operational
network configuration and service data tables:
- network definition tables
- transport network
- external terminal network
- hosts
- routing tables
- user profiles (copy)
- terminal profiles (copy)
N̲M̲H̲
The NMH will contain of the following service data.
- network definition tables (copy)
- user profiles
- terminal profiles
- equipment inventory
- accounting data
N̲o̲d̲e̲
Each node will contain its own local routing table
covering its part of the transport network and also
tables defining its connected external network:
- local routing table
- external terminal table
- host attachment table
- application service table
The node will be able from its local network configuration
definitions to perform routing between terminals and
hosts in its local environment without involving the
NCC.
H̲o̲s̲t̲
Each host (IBM, UNIVAC, HONEYWELL) will keep a complete
description of the terminal access network mapped into
the environment applicable to each individual host
type.
C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲
Changes in local configuration tables and service data
tables will be indicated by the network component,
at the NCC level which keeps the entire network definition.
…86…1 …02… …02… …02… …02…
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲3̲.̲6̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲O̲n̲-̲l̲i̲n̲e̲ ̲I̲n̲v̲e̲n̲t̲o̲r̲y̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT Incl. in "NMH
Inventory Data Base Mngt."
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The custom development is related to the generation
of the ACDN specific database.
An online inventory will be provided as required and
it will be part of the entire Network Configuration
Data Base residing in the NMH as described in section
III 4.7.5.1.
The items in this inventory will be all line replaceable
units in the network including the units of the existing
network.
Each unit has a record defining all external logical
and physical connections with cross reference to device
path definitions for consistency checking.
The method of accessing the inventory is illustrated
in section III 6.11.5 ff. - an example is shown on
fig. III 6.11.5-1.
Section III 6.11.6 and III 4.7.5.4 outline the principles
for report generation according to the proposed database
concept.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲R̲ ̲3̲.̲7̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲C̲a̲p̲a̲b̲i̲l̲i̲t̲y̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The required functions are already separated logically
in the NMH as it appears from section III 6.11 ff.
and section III 4.7 ff.
The NMH connects to the backbane network as a general
purpose host and may as such in principle be accessed
from any location connected to the network.
Geographical separation is possible without any changes
to this proposal.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲R̲ ̲3̲.̲8̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲L̲i̲m̲i̲t̲e̲d̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲o̲n̲t̲r̲o̲l̲
̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
G̲l̲o̲b̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲
In the proposed ACDN all network components can be
globally controlled from the NCC, which has the master
network configuration and service data tables and files
(see also response to R 3.5). A complete set of operator
and user commands is given in section 4.6 which also
identifies possible originating network locations.
N̲C̲C̲ ̲B̲a̲c̲k̲u̲p̲
The ACDN network has two NCC sites, one being the actual
NCC, the other being standby. Switchover to the standby
NCC occurs as a result of a catastrophic failure at
the currently active NCC. The switchover to the backup
NCC occurs within seconds without disrupting the overall
network services. The NCC switchover will occur without
dependancy of the NMH; all relevant network configurations
are resident within the backup NCC. This is described
in section 4.14. Also see alarms and status below.
L̲o̲c̲a̲l̲ ̲N̲o̲d̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Although the ACDN will be fully capable of unmanned
node operation, a number of network control and supervision
functions may be performed by network supervisor and
technician staff using the operator position at the
node control processor of a nodal site. The scope
of command/functions is identified in section 4.6 (table
4.6). Nodal Site operations are describer in section
4.10. The scope of functions includes:
- Status request functions (all network status)
- External resource control (ICC trunks, ICC's, devices
and host participants)
- Remote node interface (dumping and diagnosing)
- Local H/W and S/W troubleshooting and verification
Standby equipment and transmission resources are activated
through the standard operator commands described in
section 4.8.5.4 (summarised in section 4.6). Remote
diagnostic and dumps are likewise activated by operator
commands (see section 4.13).
A̲l̲a̲r̲m̲s̲ ̲a̲n̲d̲ ̲S̲t̲a̲t̲u̲s̲ ̲R̲o̲u̲t̲i̲n̲g̲
Events occurring in ACDN which shall be displayed to
an NCC operator are routed to both the active and standby
NCC. Thus the backup NCC has access to all active
alarms in a switchover situation. Also all status
information flowing in the network are routed to both
NCC's.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲R̲ ̲3̲.̲9̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲C̲e̲n̲t̲r̲a̲l̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Software configuration control library and the overall
centralized database reside at the NMH.
Distribution of new software and tables is controlled
by the active NCC.
A NCC supervisor will be able to operate all nodes
and the EMH as an on-site system operator, i.e. all
operating system commands and reports to the on-site
operators console may be transmitted to/from the NCC
supervisory position by means of this feature. The
NCC operator will be able to install new tables and
software without disrupting the normal network operation.
This feature will also provide for remote maintenance
and remote software debugging.
The time to downline load software is limited by the
transmission time as the CPU processing time is negligible.
The transmission time depends on:
- message length
- priority
For high priority down-line load of routing tables
maximum 0.1 second is used. For low priority software
load files the maximum time is not predictable.
This time is not important as the inclusion of new
software is executed in two phases:
- load of software to node and reception of acknowledgement
- start of loaded software
Nodal software dump (post mortem dump) will be produced
after each non-recoverable PU failure - caused by hardware
or software - may also be produced on operator request
from OC or NCC.
The tools available to analyze the dump are standard
software utilities for listing HEX, ASCII, - disassembly,
-searching, - debugger, - other utilities listed in
CR 80 Handbook, section 4.10.
A node contains 3 versions:
- previous
- current
- a being updated
of software, which can be offline loaded from the NCC.
During load and start of the new software the NCC receives
status of the updating process. In case of malfunction,
the NCC can request a reversion to a previous version.
The number of software versions maintained in the network
is not limited by hard limits, but should be restricted
to 3.
Software versions are separately downline loaded from
the NCC to the nodes. The versions originate from the
central configuration control library at the NMH where
all maintenance should be made.
Whether or not different software versions can be used
at different nodes cannot be answered as it depends
on the compability between the versions.
The procedures and tools for software development is
discussed in the response to requirement 3.15.
The application software languages used in the network
software are:
- SWELL
- PASCAL
- COBOL (only NMH)
Refer to CR80 Handbook, section 4.10.2.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲3̲.̲1̲0̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲C̲o̲s̲t̲i̲n̲g̲-̲B̲i̲l̲l̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT Included in
NCC integration.
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The data collected for cost and billing purposes are
listed in detail in section 4.11.3. These are the standard
statistics generated for all sessions established on
ACDN.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲R̲ ̲3̲.̲1̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲-̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲S̲e̲n̲s̲i̲t̲i̲v̲i̲t̲y̲
̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Network (transport and external device attachments)
changes will be totally transparant at the host application
software level. For each host participant, the ACDN
network will be mapped into the network environment
applicable for each type of host (IBM/SNA, Univac/DCA)
Network reconfigurations will be reported to the appropriate
hosts through the Host access service layer of each
node such that each host will have an uptodate picture
of the network. This is further described in section
4.8.5.4.3. It should be noted that the transport network
configuration itself has no significance at the host
level at all.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲3̲.̲1̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: H̲a̲r̲d̲w̲a̲r̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT: 1 MM of WD
F/W
dev & 1 MM
of
LTU F/W dev.
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
An external H/W monitor is provided as part of the
Watch Dog system.
At the OC connected to the Watch Dog, the following
statistics can be displayed:
o CPU load in every CPU in every PU connected to
the Node
o Queue Status in all PUs connected to the Node
o Disk Load
o Number of Disc Accesses
o Traffic Load on each LTU channel connected to the
Node
o Buffer status in LTUs
o Protocol Statistics from LTUs, Retransmission Counters,
CRC error counts etc.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲R̲ ̲3̲.̲1̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲-̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲S̲y̲s̲t̲e̲m̲
̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The Query languages available for the ACDN will be
a specially tailored set of tools aimed at Air Canadas
requirements. The query statements to be entered from
interactive terminals or batch as desired will follow
the syntax of normal Pascal statements.
The philosophy behind the query language is that the
NMH software will accept user entered query statements
and include these during preprocessing of a Pascal
program before compilation and execution.
Normal query interactions, where comparatively simple
selection criterias are used for primary investigations,
can be enhanced to more detailed or permanent report
request, because all capabilities inherent in Pascal
can be used. This enhancement capability is a feature
which promotes productivity of programmers.
Any overhead due to compilation will be negligible
compared to faster execution, because resource consuming
interpreters are avoided. If response times are critical
for dedicated recurrent query situations, loadable
software can easily be developed for these situations
because of the flexibility of the query language. These
are no restriction of the language concerning data
base access.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲R̲ ̲3̲.̲1̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲M̲o̲d̲e̲l̲l̲i̲n̲g̲ ̲T̲o̲o̲l̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The Network Modelling Software Package is a simulation
model of the network. All traffic originating sources
like terminals, external networks gateways and host
will, within the model, generate traffic based on type,
time and length distrivuted transactions.
The processing with all subsystems, nodes and hosts
will also be simulated to provide a realistic model
of the system.
During work with the proposal Christian Rovsing has
produced various sizing reports based on a simplified
mathematical model. These reports are shown in Appendix
D and they include:
- baseline network transaction volumes
- 1991 projection of transaction volumes
- Nodal switch processors, end-to-end response time
- Nodal switch processor, CPU utilization
- Nodal switch processor, memory utilization
- query modelling
These reports will be refined during implementation,
and a model will be programmed in Pascal for installation
on the NMH (ref. section 5 for detailed sizing data).
The existing equipment, i.e. hosts, will contribute
to the total model in order to give a realistic view
of the total network.
This is done by mathematic modelling of the existing
equipment in using the same subsystem models as for
Christian Rovsing provided equipment. Air Canada will
be asked to assist in providing realistic parameter
data for all existing equipment which is included in
the network simulation model.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲3̲.̲1̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲T̲e̲s̲t̲ ̲a̲n̲d̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲
̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT 25 manmonths
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
1. Custom development is required for emulation of protocols,
traffic types of the existing ACDN.
2. T̲e̲s̲t̲ ̲M̲o̲d̲e̲s̲
The online test configurations are the following:
- Using the security system to establish a logical
isolated user, terminal, host, service configuration
- Using redundant equipment to establish a separate
network
Both test modes can be accomplished in a secure manner
and without physical separation of H/W due to the inherent
security partitioning features of the CR80 architecture
and the operating system DAMOS.
2.1 T̲e̲s̲t̲ ̲M̲o̲d̲e̲ ̲1̲
This test mode is accomplished using the security system
of the basic ACDN as discussed in the response to requirement
2.7.
2.2 T̲e̲s̲t̲ ̲M̲o̲d̲e̲ ̲2̲
This test mode is accomplished using redundant H/W
to establish a separate network. The attached figure
- Fig. REQ 3.15-1 - gives a node configuration using
test mode 2.
The marked up elements are dedicated to the test network.
This setup is completely determined by configuration
tables similar to thosse which apply to the normal
network.
3. T̲e̲s̲t̲ ̲D̲e̲b̲u̲g̲g̲i̲n̲g̲ ̲F̲e̲a̲t̲u̲r̲e̲s̲
The standard software test tools are proposed as debugging
features. The software development and debugging features
are described in narrative form in the CR80 Handbook
section 4.10, page 4-123 to 4-185. This software includes
the following online test facilities:
- Debugger - ref. CR80 Handbook section 4.10.4.5,
page 4-159
- Online test facility - ref. CR80 Handbook
section 4.10.4.3.4,
page 4-157, 158
- Other test facilities in this section are also
feasible in this context
The real-life test environment is provided by the "Automated
Test and Emulation System" (ATES), developed by Christian
Rovsing for real-life test of major military communication
systems.
The software driving this system may be downline loaded
via the NMH and executed on redundant equipment in
the nodes, the front-ends or the EMH.
The functional capabilities of the ATES are 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)
4. S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
As described in section 6.11.1,2 p. III 6-44,45 the
NMH provides fully for software development facilities.
Due to the security partitioning features of the CR80
and the operating system simultaneous software development,
test and operational ACDN software execution may take
place.
Normal VDU terminal preferably operating at 9.6 K baud
provides excellent user service. Generally up to 3
full time users per terminal are recommended.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : R̲ ̲4̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: G̲r̲a̲c̲e̲f̲u̲l̲l̲ ̲e̲v̲o̲l̲u̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The gracefull evolution from ACNC to ACDN is carried
out by the gateway. It is possible to route more and
more traffic from the ACNC network to the ACDN network
without interruptions.
The hosts can be interfaced to the network without
changes to the host system software and thus provide
AC with the means to have a gracefull evolution.
All required functions to make resources in the ACNC
and the ACDN networks available to each other will
be implemented in the gateway.
The necessary paths for Type A and B traffic from and
to the ACNC and ACDN networks will be provided for
in the gateway.
The interface between the networks and the gateway
is the message level protocol. The performance and
capacity of the gateway will not be less compared to
a solution where packets instead of messages were handled.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲4̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲E̲v̲o̲l̲u̲t̲i̲o̲n̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The basic structure of the proposed ACDN network is
built around the principles of having any-to-any communication,
meaning that whether it is communication involving
geographical distances or within a local area, should
not have any affect on the utilization of the network.
This means that local area network can be an integrated
part of the ACDN network with all the belonging functions
of office automation, videotex, electronic mail, fascimile
and voice.
It will be possible to interface new CBX uses to the
ACDN network, because they are belonging to one of
the above mentioned classes.
Since the network will use distributed processing,
the interfacing of CBX networks will be at the most
appropriate place. The network shall provide for the
necessary intelligence to do the interfacing.
Network access will be handled in the normal way, meaning
that the terminals in the CBX network will have to
ask the NCC for permission to access the network. This
permission is granted, if the user profiles and device
profiles allow it.
The CBX terminals would have a virtual path set up
just like any other terminal.
The CBX network will be looked at as a sub-network
to the NCC and be serviced in very much the same way.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲4̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲H̲o̲s̲t̲ ̲M̲i̲g̲r̲a̲t̲i̲o̲n̲ ̲P̲l̲a̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
A detailed migration plan for the whole project with
milestones is in Document I, chapter 3.4.1.
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲5̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT N/A
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE!
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The maintenance philosophy is influenced by the very
high degree of reliability of the CR hardware and the
n + 1 redundancy configuration of the systems. Preventive
maintenance will be minimal, restricted to specified
periodic inspections of LEDs, cleaning of dust filters,
etc., as well as implementing engineering change notices.
Emergency maintenance will consist of swap-out of faulty
modules and running off-line diagnostic software.
On-site tools and test equipment requirements will
be minimal because of the maintenance strategy proposed.
A list of special tools and test equipment will be
submitted to Air Canada during the planning phase of
the project. Special tools and test equipment will
be provided at the sites during installation of Christian
Rovsing equipment.
A Recommended Spare Parts List (RSPL) will be submitted
to Air Canada during the maintenance planning phase
of the project. Upon approval, it will become the Approved
Spare Parts List (ASPL). The ASPL will be composed
of:
- CR80 modules
- Special OEM equipment
- Standard OEM equipment
The CR80D spares complement will be derived from accepted
probability formula calculations. OEM spares complement
will be based jointly on manufacturers recommendations
and Christian Rovsing experience.
The ASPL will be deployed in two levels. First, critical
modules will be kept at the nodal sites. Second, at
the Toronto node, where continuous maintenance and
maintenance administration is planned, the remaining
components of the ASPL will be maintained and dispatched
to the remote nodes as required. The Toronto site will
serve as a central depot for shipping and receiving
boards requiring repairs at the Christian Rovsing facility
in Ballerup, Denmark.
The equipment maintenance support function will be
carried out by Christian Rovsing's subcontractor, CNCP
Telecommunications, unless Air Canada decides upon
the stated option of self maintenance. In either case,
the qualificaton prerequisites are the same; at least
five years prior experience as a computer technician
plus an eight-week maintenance course at Christian
Rovsing facilities in Denmark. Assuming that CNCP performs
the maintenance, the following levels of coverage are
initially proposed:
- Toronto: 240 hours per month requirement for maintenance,
parts management, liaison, reports generation,
etc. provided through continuous, on-site maintenance
coverage by CNCP computer technicians.
- Montreal: 60 hours per month requirement covering
on-site maintenance plus continuous on-call coverage
by CNCP computer technicians.
- Winnipeg: 55 hours per month requirement covering
on-site maintenance plus continuous on-call coverage
by CNCP equipment technicians.
A fully trained complement of CNCP technicians will
be present during the installation phase at the three
sites.
For a detailed explanation of all aspects of equipment
maintenance support, please refer to Document III:
Technical proposal:
- Section 9.2 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲S̲u̲p̲p̲o̲r̲t̲,
pages 5-16
- Section 9.3 T̲r̲a̲i̲n̲i̲n̲g̲, page 23
- Section 9.6 S̲p̲a̲r̲e̲ ̲P̲a̲r̲t̲s̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲i̲n̲g̲, page 62
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲5̲.̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲r̲a̲i̲n̲i̲n̲g̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT 39 M/M (includes
managerial, technical plus secretarial effort)
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The training program proposed by Christian Rovsing
has been designed to permit Air Canada to operate the
entire ACDN independently. The training program will
also enable the sub-contractor, CNCP, to install and
maintain the hardware configurations independent of
Chrsitian Rovsing.
Courses have been compiled for the following personnel
categories (AC and CNCP):
- System Management Staff
- Communications Specialists
- Software Programmers
- Network Managers and Operators
- Computer Technicians
Christian Rovsing has a formal training organization
comprised of a manager, technical writers, and instructors.
A highly structured course format is employed. Trainihng
techniques include:
- Lecturers
- Team work and reporting
- Group discussion
- Hands-on practical training
- Tests and questionnaires
Training material consists of Student Reference Guides,
Hand-Outs, the appropriate System Documentation, plus
access to the complete Christian Rovsing library. All
training material presented by Christian Rovsing may
be reproduced by Air Canada, but only for the exclusive
use in the further training of Air Canada or CNCP personnel.
Initial training will be conducted at Christian Rovsing
facilities in Ballerup, Denmark. Subsequent, optional
courses will be offered at the same facility.
For a more detailed description of training, please
refer to Document III, Technical Proposal:
- Section 9.3 T̲r̲a̲i̲n̲i̲n̲g̲, pages 17-29
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲5̲.̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? NO
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT N/A
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
Following installation acceptance, Christian Rovsing
will provide a systems analysis and software programming
support service to Air Canada. This service will consist
of the following elements:
- design and implementation of modifications and
new requirements for system and applications software
- diagnostics and corrections to software faults
- control and maintenance of software documentation
- other expertise as might be required
The support service would continue until such time
as Air Canada had developed their own capabilities
in each of the aforementioned elements. Software training
for Air Canada programmers will be initially available
at Ballerup, Denmark.
Software support and training is referenced in Document
III: Technical Proposal:
- Section 9.2.4.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲u̲p̲p̲o̲r̲t̲, page 16
- Section 9.3.2 T̲r̲a̲i̲n̲i̲n̲g̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲, pages 18 and
24
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲5̲.̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT 31 M/M (technical,
drafting, secretarial effort)
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
In compliance with the REP, the following documentation
will be provided with the Christian Rovsing System:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲I̲T̲E̲M̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲S̲E̲T̲S̲ ̲
̲ ̲ ̲ ̲ ̲
System Description Manual 5
Installation Manual 5
System Operator Manual 5
Network Operator 5
Maintenance Manual 8
Assembly Breakdown 5
Inventory Manual 5
Module Description Manual 5
ASPL 5
Peripheral Equipment Manual 5
Tools and Test Equipment Manual 5
Programming Development Tools 5
Software Listings 1
It should be noted that a preliminary set of all documentation
will be presented for review of compliance to Air Canada
standards, and following approval by Air Canada, final
versions will be presented in the numbers previously
specified.
For a more detailed description of documentation, please
refer to Document III: Technical proposal:
- Section 9.5 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲, pages 54-61
RESPONSES TO AIR CANADA REQUIREMENTS
REQUIREMENT REFERENCE : ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲ ̲5̲.̲5̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
REQUIREMENT DESCRIPTION: ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
IS REQUIREMENT SATISFIED BY THIS PROPOSAL? YES
IS CUSTOM DEVELOPMENT REQUIRED? YES
ESTIMATED EFFORT REQUIRED FOR CUSTOM DEVELOPMENT N/A
DOES THIS REQUIREMENT AND/OR YOUR SOLUTION TO THIS REQUIREMENT
ADVERSELY AFFECT (IMMEDIATE OR LONG TERM) ANY OTHER NETWORK
REQUIREMENT(S). IF SO, PLEASE ELABORATE! NO
The response must clearly distinguish between existing functionality
and custom development.
DESCRIBE IN DETAIL HOW ITEM IS OR WILL BE SATISFIED:
The modularity of the Christian Rovsing equipment permits
remodeling of system layouts to accomodate customer
space availability. Within the first month following
contract award, it is proposed that Air Canada, Christian
Rovsing and CNCP Telecommunications jointly participate
in site surveys to finalize site preparation requirements
and determine optimal equipment layouts within whatever
space availability constraints which might exist.
For the purpose of the Christian Rovsing proposal,
however, typical layouts have been designed for the
three nodal sites. Toronto, Montreal and Winnipeg.
These layouts accommodate anticipated expansion through
1991.
For a more detailed description of installation planning
and typical site layouts, please refer to Document
III: Technical proposal:
- Section 9.4.2 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲ ̲P̲l̲a̲n̲n̲i̲n̲g̲,
pages 31-33
- Section 9.4.3.3 T̲y̲p̲i̲c̲a̲l̲ ̲L̲a̲y̲o̲u̲t̲,
pages 39-46
Based upon the final equipment configuration proposal,
each site will have an equipment room containing lineups
for Nodal Switch and Nodal Control processing units.
In addition, Toronto will have separate lineups for
the Electronic Mail and Network Management Hosts. All
lineups are designed to present a logical appearance
to operating and maintenance personnel, and to present
easy access to equipment and attached cabling. It should
be noted that the proposed equipment can accommodate
either top or bottom cable entrance, thus obviating
the strict requirement for raised flooring.
At the Toronto site, and to a limited extent the Montreal
site where an alternate NCC function will be located,
there are human factors to consider, i.e. the separation
of man and machine. It is proposed that a wall with
partial glassed-in sections be built to isolate the
NCC, EMH and NMH positions from the mainframe (plus
disc and tape unit) equipment. A room divider could
be used to further isolate the NMH function, where
software development and testing will take place, from
the other network positions.
Site facility requirements can be summarized as follows:
Floor Approx. Power Heat
Space Weight Usage Dissipation
(m…0e…2…0f…) (kg) (kw) (kcal/h)
I̲n̲i̲t̲i̲a̲l̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Toronto 125 4,700 25.8 22,200
Montreal 72 2,200 13.2 11,300
Winnipeg 40 1,900 11.9 10,200
1̲9̲9̲1̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
Toronto 125 5,700 31.6 27,200
Montreal 72 2,900 17.4 14,900
Winnipeg 40 2,700 16.1 13,800
Note: Floor load of heaviest rack is
300 kg
̲ ̲ ̲ ̲ ̲ ̲ = 476 kg/m…0e…2…0f…
0.63 m…0e…2…0f…
Power supplied to the equipment is fed from fuse-protected
208V AC or 110V AC outlets, 60 Hz. All equipment is
supplied with suitable mains filters and have overvoltage
protection against component damage. UPS is not mandatory
although a power interrupt will cause software recovery
of the affected PU.
CCITT recommendations specify a maximum of 50 feet
for V24 and V28 electrical interfaces. This distance,
however, depends among other factors, on cable quality
and the transmission speed used.
For further detail regarding facilities requirements,
please refer to Document III: Technical proposal:
- Section 8.0 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
̲a̲n̲d̲
C̲o̲m̲m̲o̲n̲ ̲A̲s̲p̲e̲c̲t̲s̲,
pages 2-14
- Section 9.4.4.3 T̲y̲p̲i̲c̲a̲l̲ ̲L̲a̲y̲o̲u̲t̲, pages 39-53
