top - download
⟦0a9775879⟧ Wang Wps File
Length: 14145 (0x3741)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN64.00«
Derivation
└─⟦2d3b1b389⟧ Bits:30006261 8" Wang WCS floppy, CR 1006V
└─⟦this⟧ »~ORPHAN64.00«
WangText
J…00……00……00……00…@…02……00……00…@
?…0c…?…0f…? >…09…>…02…>
=…0a…=
<…09…;…08…;…0f…;…00…;…05…;…06…:…0e…: :…05…9…0c…9…02…9 8…0c…8…0f…8…06…8…07…7…08…7…00…7…01…6…08…6…09…6…00…5…09…5…01…5…86…1 …02… …02… …02… …02…
CHAPTER 3
Page #
DOCUMENT III TECHNICAL PROPOSAL Apr. 29, 1982
LIST OF CONTENTS Page
3. PROPOSED SOLUTION .............................
4
3.1 Introduction ...................................
5
3.2 Proposed Technical Solution ....................
7
3.2.1 Scope of Air Canada Data Network ...............
7
3.2.2 Proposed Network Architecure ..................
11
3.2.2.1 Network Interface Environment ..................
15
3.2.2.2 Communication User Environment .................
16
3.2.2.3 Data Transmission Environment ..................
19
3.2.2.4 Data Link Envronment ..........................
20
3.2.2.5 Network Service Environment ....................
21
3.2.2.6 Network Topology................................
23
3.2.2.7 Network Architecture Realisations ..............
26
3.2.3 Fnctional Overview ............................
28
3.2.4 External Environments ..........................
31
3.2.5 Deliverables ...................................
34
3.3 Proposed Hardware Equipment ....................
40
3.4 Proposed Software Packages .....................
44
3.4.1 Access Software Package.........................
48
3.4.2 Nodal Switching Software Package................
50
3.4.3 Network Control Software Package...............
52
3.4.4 Network Management Software Package.............
54
3.4.5 Electronic Mail Software Package................
55
3.5 Performance ....................................
57
3.5.1 Node Modelling ................................
58
3.5.1.1 End-to-End Response Time .......................
58
3.5.1.2 Processor Utilization and Capacity..............
59
3.5.1.3 Memory Utilization .............................
60
3.5.1.4 Internodal TrunkUtilization ...................
62
3.5.2 Gateway ........................................
63
3.5.3 EMH Modelling ..................................
64
3.5.4 Reliability and Availability ...................
67
3.6 Baseline Capacity and Projected Growth .........
69
3.6.1 Baseline Capacity ..............................
69
3.6.2 Projected Growth ..............................
70
3.6.3 Block Diagrams .................................
72
3.7 Telecommunications .............................
77
3.8 Options ........................................
78
3.8.1 Videotex ......................................
80
3.8.2 High Density Digital Tape Recordings ...........
83…86…1 …02… …02… …02… …02… …02…
LIST OF FIGURES
3.1-1 Present Air Canada Data Networks.......... 6
3.2-1 Proposed Architecture..................... 12
3.2-2 ACDN/081 Reference Model Mapping ......... 14
.2-3 Network Protocols ........................ 17
3.2-4 Topology Example ......................... 24
3.2-5 C-NODE Partitioning ...................... 25
3.2-6 Network Architecture Realizations ........ 27
3.2-7 Air Canada Computing Enviroment ......... 29
3.2-8 Proposed Network Architecture ............ 35
3.2-9 Hardware and Software Mapping ............ 35
3.3-1 Proposed Node Network .................... 41
3.4-1 ACDN Software Packages ................... 45
3.4-2 ACDN Sftware Structure .................. 45
3.4-3 ACDN Software ............................ 47
3.4-4 Network Interfaces Environment ........... 51
3.6-1 Projected Growth Toronto ................. 73
3.6-2 Projected Growth Montreal ............... 74
3.6-3 Projected Growth Winnipeg ................ 75
3.6-4 Projected Growth, EMH .................... 76
3. P̲R̲O̲P̲O̲S̲E̲D̲ ̲S̲O̲L̲U̲T̲I̲O̲N̲
To the full extent that Air Canada is embarking on
establishing a network base for the 1980s with the
knowledge of the positive impact this will have on
AirCanadas operations, services to the passengers and
to the airline industry's commercial infrastructure,
we have presented in this chapter our solution in the
context of a broad perspectiv over the trends in data
communications industry in the 1980s
The key themes behind our proposed solution are:
High availability: Through fault tolerance
and
redundant hardware and
through a unique network
control philosophy.
Granular Expandability: Through a scheme that
exploitsmultiprocessing
configuratons and
distributed functions.
Investment Protection: Through a networking scheme
that supports heterogenous
hosts, data transport
services, terminal types
and a networking scheme
based on available standards
…02…Subscriber services: By exploiting available
standard software and
firmware for host support
and terminal devices support.
3.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The scope of this chapter is to convey to the Technical
Management function in Air Canada, the underlying precepts
of the solution proposed by Christian Rovsing o meet
the functional requirements contained in the Air Canada
RFP.
This chapter also serves to provide a high level breakdown
of the proposed Air Canada Data Network including the
associated rationale. The breakdown is covered in terms
of hardwae and software architectures. The software
is presented in terms of the 7-layer OSI reference
model. Additionally, this chapter presents the predicted
performance and response times.
The proposed solution is presented in a broad context
in secton 3.2. Subsection 3.2.1 provides the scope
of the backbone network as perceived by Air Canada
while subsection 3.2.2 presents the proposed network
architecture by covering internal environments, network
topology together with possible network relizations.
Subsection 3.2.3 gives a functional overview on the
proposed Air Canada Data Network, while subsection
3.2.4 defines and presents the external "environments"
to which the proposed Air Canada Data Network provides
service.
The deliverale hardware and software mapping on the
environments of the architecture is provided in subsection
3.2.5.
Section 3.3 provides the high-level break-down of the
hardware.
The software functional basis and structure is presented
in section 3.4. his section covers interfaces to the
backbone network from users, i.e. from host computers,
other networks, via the Gateway to the existing network,
and to terminal equipment.
Results of the performance analysis, i.e. response
times and capacitie, are presented,in section 3.5.
Finally, section 3.6 discusses the projected growth
capabilities of the network with respect to capacity
and functionality, 3.7 describes the telecommunication
support provided by CNCP, while 3.8 discusses potentia
growth areas.
Figure III 3.1-1 PRESENT AIR CANADA DATA NETWORKS…86…1 …02… …02… …02… …02…
3.2 P̲r̲o̲p̲o̲s̲e̲d̲ ̲T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲S̲o̲l̲u̲t̲i̲o̲n̲
3.2.1 S̲c̲o̲p̲e̲ ̲o̲f̲ ̲A̲C̲D̲N̲
Air Canada Data Network (ACDN) is perceived as a transparent
common communication service capable of interfacing
a variety ofterminals, terminal concentrators, and
a variety of general purpose mini or mainframe based
computing facilities.
The computing facilities of Air Canada as they exist
today, are presented in a generalized and simplified
view in Figure III 3.1-1 Present Air Canada Data Networks".
Each of the networks provides specific sets of services
to the user.
The discernible premises for the RFP are:
... a high degree of transparancy in the network
necessitated by the diversity of users and ervices
... a need to interface to and permit access to
application resources in UNIVAC, HONEYWELL, IBM
mainframes.
... a need to provide network management and admini-
stration facilities that can be exploited by the
network maintenane staff organization at the
central a̲n̲d̲ remote sites.
... a need to support new services like facsimile data
transmission and digitised voice transmission.
... a need to coexist with external networks that
provide complementary services nd coverage.
... a need to realise a stable migration from the
existing network environment to an enhanced
network environment.
When the above premises are mapped on to the available
networking solutions from Christian Rovsing a primary
ationale for the proposed Air Canada Data Network (ACDN)
is seen to evolve.
The solution to the Air Canada Data Network proposed
herein, is based on a network architecture which has
evolved over the last five years and is used in national
as well as interational private networks, where high
performance, reliability, security and flexibility
were essential.
The proposed network architecture has been designed
to create a communication mechanism which supports
a wide range of user applications, hostcomputer systems
and interconnect technologies. Specifically, the goals
are the following:
a. C̲r̲e̲a̲t̲e̲ ̲a̲ ̲C̲o̲m̲m̲o̲n̲ ̲U̲s̲e̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲:̲ The application
interface to the network should support a broad
spectrum of application communication requirements
andshould be common across the varied implementations.
Within such a network environment, applications
may be moved among the systems in the network,
with the common interface hiding the internal characteristics
and topology of the network.
b. S̲u̲p̲p̲o̲t̲ ̲a̲ ̲W̲i̲d̲e̲ ̲R̲a̲n̲g̲e̲ ̲o̲f̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲a̲c̲i̲l̲i̲t̲i̲e̲s̲:̲
The network should be adaptable to changes in
communication technology and operate with a variety
of communication channels using appropriate cost
effective technology. Today this may be leased
ground cicuits, in a few years it may be satellite
channels.
c. B̲e̲ ̲C̲o̲s̲t̲ ̲E̲f̲f̲e̲c̲t̲i̲v̲e̲:̲ The network should approach
the efficiency and performance of a network designed
specifically for a given application. In addition,
factoring in the reduced development efort by using
an existing network product, a distributed application
development should have a good performance to cost
ratio.
d. S̲u̲p̲p̲o̲r̲t̲ ̲a̲ ̲W̲i̲d̲e̲ ̲R̲a̲n̲g̲e̲ ̲o̲f̲ ̲T̲o̲p̲o̲l̲o̲g̲i̲e̲s̲:̲ The architecture
should support communication between users independent
of the itervening data transport network. The interconnection
structure of the computers and communication facilities
should not affect the logical communication capabilities
of the applications.
e. B̲e̲ ̲H̲i̲g̲h̲l̲y̲ ̲A̲v̲a̲i̲l̲a̲b̲l̲e̲:̲ The overall operation of
the netwrk should not be adversely affected by
the failure of a topologically noncritical node
and/or channel.
f. B̲e̲ ̲E̲x̲t̲e̲n̲s̲i̲b̲l̲e̲:̲ The architecture should allow for
the incorporation of future technology changes
in hardware and/or software: for the movement of
functions across the hardware/oftware boundary,
taking advantage of new technological innocations
in both domains; and for the subsettability of
functions to allow smaller, lower performance nodes.
g. B̲e̲ ̲E̲a̲s̲i̲l̲y̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲b̲l̲e̲:̲ The architecture should
be independent of the intrnal characteristics of
the hosts and their operating systems and be easily
and efficiently implemented on a wide variety of
heterogeneous hardware and software.
h. U̲s̲e̲ ̲a̲ ̲H̲i̲e̲r̲a̲r̲c̲h̲i̲c̲a̲l̲ ̲L̲a̲y̲e̲r̲e̲d̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲:̲ This will
create a highly flexible structue with ease of
layer replacement and modularity.
i. U̲n̲i̲f̲o̲r̲m̲l̲y̲ ̲A̲d̲d̲r̲e̲s̲s̲ ̲a̲l̲l̲ ̲N̲o̲d̲e̲s̲:̲ The topology should
not restrict access. Nodes should be characterized
only by the functions they perform, and not by
their location in the network.
j. I̲m̲p̲l̲e̲m̲e̲n̲t̲ ̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲a̲t̲ ̲t̲h̲e̲ ̲H̲i̲g̲h̲e̲s̲t̲ ̲P̲r̲a̲c̲t̲i̲c̲a̲l̲ E̲f̲f̲i̲c̲i̲e̲n̲t̲
̲L̲e̲v̲e̲l̲ ̲W̲i̲t̲h̲i̲n̲ ̲t̲h̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲:̲ Such functions as
network control and maintenance should execute
at the level of application programs.
k. B̲e̲ ̲D̲y̲n̲a̲m̲i̲c̲:̲ Protocols should be flexible to change;
new modules an functions should be easily added
within the structure.
The general purpose computer facilities may include
software for supporting remote terminals and associated
communication procedures. ACDN, as conceived and presented
in this proosal, excludes all such facilities in their
entirety. However, the implied transparancy in the
ACDN is such that a̲n̲y̲ general purpose computing facility
can be interfaced to ACDN.
It is our conviction that in the 1980s there is no
real need to disinguish between terminals and computing
facilities, and as such we use the words synonymously.
However, there is a distinction between the interfacing
mechanisms which are attachments to the ACDN and those
which are participants. This distinctio is as follows:
a. A̲t̲t̲a̲c̲h̲m̲e̲n̲t̲s̲ ̲t̲o̲ ̲A̲C̲D̲N̲
…02…Any computing facility can be interfaced to the ACDN
as
an
"attachment".
Attachment
implies
that
a
computing
facility,
irrespective
of
the
complexity
and
scope,
behaves
like
a
single
terminal
or
a
clster
of
terminals
with
predetermined
characteristics.
…02…Attachment implies that a computing facility so
interconnected does not play any role in providing
and controlling the resources made available to
the whole spectrum of ACDN users.
b. P̲a̲r̲i̲c̲i̲p̲a̲n̲t̲s̲ ̲i̲n̲ ̲A̲C̲D̲N̲
Any computing facility can be interfaced to ACDN
as a "participant". Being a participant implies
that application resources contained in that computing
facility are made available to all ACDN users.
The control functions in he ACDN monitor the status
of the application resources in each participant
and maintains the validity of the resource status
on a network wide basis. Such a participant is
also referred to as a "HOST" synonymously.
