top - download
⟦b780002d2⟧ Wang Wps File
Length: 106734 (0x1a0ee)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN60.00«
Derivation
└─⟦2d3b1b389⟧ Bits:30006261 8" Wang WCS floppy, CR 1006V
└─ ⟦this⟧ »~ORPHAN60.00«
WangText
J…00……00……00……00…<…02……00……00…<
;…0c…;…0f…; :…09…:…02…:
9…0a…9
8…09…8…00…8…07…7…08…7…0d…7…0e…7…06…6…0c…6…0d…6 5…0a…5…0c…5 5…07…4…0e…4…0f…4…00…3…08…3…09…3…00…3…01…2…08…2…01…1…09…1…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 2̲0̲4̲1̲A̲…00…AIR CANADA
PROPOSAL …00…ba …00…FR
…00…DOC. III Chapter 3 …00…2̲0̲…00…0̲4̲…00…8̲2̲…00…0̲8̲…00…5̲5̲…00… ̲ ̲ ̲7̲…00…1̲0̲…00… ̲1̲1̲8̲3̲8̲…00…16…00…07…00…82…00…14…00…04…00…
…00…00…00… 13…00…2̲7̲…00…0̲4̲…00…8̲2̲…00…2̲0̲…00…4̲0̲…00…16…00…07…00…82…00…14…00…05…00…1006V…00… 83…00… ̲ ̲1̲6̲…00…48…00…
1448…00… ̲3̲4̲7̲23…00……10……00……00……00……11……02……00……10……00……01……10……05…f…10……11……02……80…*̲J̲…15……05……00……00……00……00……00……00……00…B
?̲…01…J…00……00……00……00…9…0a……00……00…9…0b…9 9…07…8…0c…8…01…7…0a…7…0b…7…02…6…0b…6…01…5…08…5…0f…5…00…5…05…5…06…4…0e…4 4…05…3…0c…3…02…3 2…0c…2…0f…2…06…2…07…1…08…1…00…1…01…0…08…0…09…0…00…/…09…/…01…/…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.
3.2.2 P̲r̲o̲p̲o̲s̲e̲d̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
This section presents the proposed Network Architecture.
The layered structure of the internal environments
of the network is presented and te basic services provided
by these layers are described, in particular the services
provided to the users in external environments . The
hardware and software which constitute the deliverables
to Air Canada are described in the subsequent section
.2.5.
In the context of the scope of the ACDN a set of interrelated
"environments" can be identified as the component parts
of the general network architecture, to which ACDN
relates.
Essential to the proposed architecture is that entities
commnicate with corresponding remote entities in the
same environment.
Figure III 3.2-1 shows the environments and their
relationship.
The following five internal environments are the component
parts of the general network architecture:
- Netork Services Environment,
- Network Interface Environment,
- Communications User Environment,
- Data Transmission Environment,
- Data Link Environment,
The Network Interface Environment provides the physical
and logical interface wih attachments and participants
to the external environment. It relieves the interconnected
equipment of the burden of providing the appearance
expected by either end of a connection.
The Communication User Environment consists of entities
that etablish and maintain an orderly exchange of information
between two users.
The Data Transmission Environment consists of entities
that provide the actual communication path through
the ACDN to support the dialogue between two users.
Fig. III 3.2-1…01…PROPOSED ARCHITECTURE…86…1 …02… …02… …02… …02… …02…
The Data Link Environment consists of firmware entities
to transport data over physical links and to support
the necessary protocol facilities dictated by the attachment
or particpant interface.
The Network Service Environment consists of entities
to support complete network control as well as the
provision of special services to users of the network.
The various communication software products are designed
in a structued manner conforming to the ISO reference
model for Open System Interconnection (OSI).
The proposed architecture is mapped on the OSI as follows:
o presentation layer ... Network Interface
Environment (NIE)
o session layer ... Commuication User
Environment (CUE)
o transport layer
o network layer ... Data Transmission
Environment (DTrE)
o link layer
o physical layer ... Data Link Environment
(DLE)
System Management functions and services:
o networ management
o system management
o layer management
o service applications ... Network Services
Environment (NSE)
Figure III 3.2-2 illustrates how these ACDN environments
are mapped onto the OSI architecture.
Figure III 3.2-2…01…ACDN/OSI REFERENCE MODEL MAPPING…86…1 …02… …02… …02… …02…
3.2.2.1 N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Network Interface Environment (NIE) as the outermost
layer provides the necessary services to any user accessing
an attachment or a partcipant. The NIE makes the user
appear as a valid end user either as defined in the
destination or through a mapping onto a virtual network
protocol.
The NIE provides this service by a conversion or translation
of the end user message level protcols and data formats
into protocol and data formats dictated by the communication
user environment of the network.
Virtual Service Providers (VSP) provide the presentation
service entities which are responsible for mapping
the end user protocol o a network conversation protocol.
VSPs are software entities which implement the following
functions:
…02…o The sequence number on the data units handled by the
end user protocol is mapped to the sequence number
of the data units handled by the netork conversation
protocol.
…02…o The segmentation and/or blocking indicators in the
end user protocol data unit are mapped into corresponding
control indicators for the data units handled by
the Session Service Providers (SSP) of the CommunicationUser
Environment.
…02…o The throughput control indicators in the end user …02…protocol
are mapped to the flow control indicators
in the conversation protocol.
…02…o The presentation control indicators in the end …02…user
protocol are mapped to the device ontrol …02…indicators
in the conversation protocol.
The NIE may provide a second level of translation or
conversion of protocols, depending on whether a host
facility is interfaced as an attachment or participant.
The second level of conversion is neded for participant
interfacing. For these, the second level of translation
converts protocols and data formats dictated by communication
I/O software in the host to the protocols and data
formats dictated by the communication user environment.
3.2.2.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲U̲s̲e̲r̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Communication User Environment (CUE) provides the
necessary services to a network user in establishing
and maintaining a conversatio with another user or
logical unit in a host.
The Transport Access Port (TAP) is a fundamental entity
of the network. The TAP is the basis for providing
a given number and type of communication channel to
the network user. It provides the mean for implementing
network resource control. The TAP has the following
characteristics:
- a finite fluctuating bandwidth
- a finite predictable error rate
- a unique identity recognisable throughout the
network
Two end users exchane data through a "conversation"
is the highest level of protocol within the network.
The conversation is by definition at a level below
the end-user-to-end-user protocol. Each end user must
have a TAP assigned before a conversation can be opened.
he conversation protocol ensures proper flow of user
messages between the associated two TAPs and provides
error recovery facilities to avoid loss of messages.
Referring to Fig. III 3.2-3, "Network Protocols",
end-user-to-end-user protocol is etermined by the complex
of the host facilities. There may be as many end user
protocols as there are unique types of hosts and distinctly
supported end user types amongst the hosts. In the
proposed ACDN there is only one conversation protocol.
Figure III 3.2-3…01…NETWORK PROTOCOLS…86…1 …02… …02… …02… …02…
The conversation is established between the Session
Service Provider (SSP) entities of the CUE. The SSP
is a software entity. The data areas and control functions
of an SSP implment the following functions:
o Accept and validate a user request for a communication
service provided by the network.
o Assign a Transport Access Port (TAP) under a unique
identity.
o Interrogate the end users and determine the basic
coversation parameters.
o Based on the conversation parameters obtained
from the user, allocate the resources to the TAP
required to support a chosen traffic type and
chosen conversation protocol characteristics.
o Reserve and bind the TAP reources from the Network
Services Environment.
The TAP services provide the operational facilities
necessary to sustain open conversations by:
o Managing resources allocated to the active …02…transport
access paths.
o Monitoring the operatio of the conversation protocols.
o Supporting the hierarchical priority system with
the following levels
- messages generated by the network services
environment to inform node or other network
catastrophic failure conditions are given
the hghest priority,
- messages generated by the NSE to change routing
primitives at the nodes are given priority
at the same level as protocol responses indicating
the loss of integrity in the end-user-to-end-
user protocol,
- transport usertraffic,
- interactive user traffic,
- batch user traffic,
- messages exchanged by the NSEs distributed
in the various nodes and the Network Control
Center for collecting statistical data, are
assigned the lowest priority.
3.2.2.3 D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Data Transmission Environment (DTrE) forms the
outermost environment of the transport network.
o The DTrE provides communication servies to a pair
of SSPs engaged in a conversation so that the total
usage of the physical media connecting the two
SSPs is maximized. This is achieved by utilizing
the datagram technology as the basis for this environment.
o The SSPs can request eiher a datagram service or
a virtual connection service from the DTrE. The
latter is achieved by the source and destination
DTrE's guaranteeing the sequence in the data flowing
between the communicating SSPs.
o The virtual connections may be "swiched" or "permanent".
o DTrE provides a number of logical channels for
transmitting data.
o Each logical channel supports traffic in both directions
and is independent of the traffic on other channels.
o DTrE assigns "ports" to communication ystem users
to access the transport network.
o For certain pre-assigned attachments or participants,
the DTrE provides permanent associations between
the relevant SSPs.
o DTrE maintain a bi-directional interface for each
trunk interconnecting te network nodes with the
Data Link Environment.…86…1 …02… …02… …02… …02…
3.2.2.4 D̲a̲t̲a̲ ̲L̲i̲n̲k̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Data Link Environment is the second inner environment
of the transport network. The DLE provides the necessary
functions to supports a Data Lin Control procedure
between two DTrE utilising conventional transmission
media.
The DLE is a homogeneous entity and supports the LAPB
procedure defined as X.25 level 2.
3.2.2.5 N̲e̲t̲w̲o̲r̲k̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Network Services Environment (NSE) provides the
facilities required to support
- connectivity of network users
- participatoryinterfaces
- maintaining the integrity of the network configuration
- collecting short term and long term statistics
on network services utilisation
- a set of commands to be used by ACDN operators
to monitor the static and dynamic statusof the
network.
The NSE is implemented in a distributed manner. The
scope of the functions to support the above facilities
is presented below.
The NSE validates a user request to get connected to
the network and use its services. Validating te request
implies prior knowledge of the user by the NSE. An
important part of the network LOGON is authentication,
i.e. the validation of the identification of the user.
A result of a successful completion of a LOGON is
the creation of the capablities against which authorization
is to be checked during subsequent network transactions.
It is emphasised that this LOGON to the network is
independent of and does not replace the LOGON procedure
that may be required by an application program n a
participatory host.
Facilities needed to access and interrogate the status
and availability of applications are provided by the
NSE. These are realised by providing a set of emulated
application programs. These application programs
interroate the responsible communication software resident
in the participating host. Such interrogations provide
the data needed by the NSE to validate connectivity
requests by a network user.
The NSE maintains the integrity of the network topology
by
- recognising link failure and implementing back-up
routing…86…1 …02… …02… …02… …02…
- recognising node failures and implementing recovery
procedures
- recognising overload on links and implementing
back up routing
- recognising catastrophic failures at he NIE level
and removing the attachments or participants from
the network.
The NSE collects end user statistics primarily at the
level of an end-user-to-end-user connection. The NSE
initialises the statistics gathering at the NIE and
CUE level hen an end user protocol is initialised.
The statistics are forwarded to the NSE once the end
user exchange is terminated.…86…1 …02… …02… …02… …02…
3.2.2.6 N̲e̲t̲w̲o̲r̲k̲ ̲T̲o̲p̲o̲l̲o̲g̲y̲
The proposed ACDN is a specific implementation of general
network topologies supported by the network architecture.
The addressing structure allows an nlimited topological
combination covering both longhaul networks, C-NETs
based on CR 80 computers and local area networks based
on X-NET systems.
The users of the architecture are connected either
to a C-NET or an X-NET.
An arbitrary group of CNETS forms a C-REGION. Similarly,
an arbitrary group of X-NETS form an X-REGION.
In a C-REGION, a longhaul region, groups of up to 16
neighbouring C-NETS may be interconnected by a highbandwidth
channel (S-NET). Such a constellation is referred t
as a C-NODE. C-NODEs may be interconnected by leased
lines or by employing the services of public data networks.
In a X-REGION, a highbandwith local region, a number
of X-NETS may be interconnected with other X-NETs via
X-NODES. Up to 16 X-NETs(and one C-NET) can connect
to the same X-NODE. Conversely, up to 16 X-NODEs can
connect to the same X-NET.
Figure III 3.2-4 illustrates the architectural topological
possibilities.
The C-NODE software is implemented by means of the
following igh level structure.
A C-NODE is a group of C-NETs, which operates under
the control of a common operating system. To facilitate
the management of system resources, each C-NET software
is isolated and controlled separately. The co-ordination
of th total resources at the C-NODE is facilitated
via the central management part of the Network Services
Environment, which stretches right across the C-NET
boundaries.
Figure III 3.2-5 illustrates this partitioning.
Figure III 3.2-4…01…Topology Example
Figure III 3.2-5 …01…C-NODE Software partitioning
3.2.2.7 N̲e̲t̲w̲o̲r̲k̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲ ̲R̲e̲a̲l̲i̲s̲a̲t̲i̲o̲n̲s̲
A number of system elements might be implemented by
combining appropriate component parts of the network
architecture. The generic ntwork elements presented
in this section highlights the realisations feasible
within the architecture. It is an attempt to provide
the Air Canada Technical Management function with the
perspectives of the proposed ACDN.
Figure III 3.2-6 "NetworkArchitecture Realisations"
illustrates how the internal environments may be combined
to form the following elements:
NCC - Nodal Control Center, which implements central
network application
NSH - Network Service Host, dedicated network elemnt,
which implement network services; e.g. a NMH
provides network administrative and planning
services while an EMH provides a protected
message service; These elements are participants
in the network.
Node - A generalized term used for an integated MIP,
TIP and switching node,
Switching Node - the switching nodes are configured
to realise the CUE, DTrE, and DLE.
Thus, it provides the basic transport
services.
HIP - the Host Interface rocessor implements a host
front-end capability combined with integration
into the network by means of the switching
node element of the HIP. The physical and
logical interface towards the host is a channel
which operates in accordance with the aplicable
mainframe vendor standards.
TIP - the Terminal Interface Processor implements
the interfaces to the various terminal devices
to be attached to the network. The TIP is
integrated with the switching node.
MEDE - the Message Entry and Dstribution Environment
are configured to realise the (remote) attachment
functions of the NIE. The physical hardware
configuration of the MEDE reflects the interfacing
requirements of the various devices to be attached.…86…1
…02… …02… …02… …02…
Figure III 3.2-6…01…Network Architecture Realisations…86…1 …02… …02… …02… …02…
3.2.3 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The proposed network provides the means for integrating
present as well as future computer and terminal facilities
assigned to the following environment:
- Host Environment
- External Network Environment
- Internal Network Environment
- Terminal Environment
The users, host applications and terminal operators,
uses a combination of the facilities implemented in
the Host, Network, and Trminal Environments together
with those of the ACDN. The ACDN interconnects the
external environments and provides a level of integration
which makes the actual network topology and application
allocation transparent to the user. This is illustraed
in Figure III 3.2-7 "Air Canada Computing Environment".
Each of these environments is described in more details
in the next section. The remainder of section summarizes
the services and capabilities of the ACDN.
In addition to the packet witch based services which
implement interconnection between users, the network
itself provides the following services:
- Network Control
- Network Management
- Protected Message Service
The network control services are provided to dsignated
personnel, network supervisors and field technicians.
These services provide a centrally controlled environment
which protects the integrity of the network and ensures
consistent service to all users.
The network management services covrs collection of
statistical information for billing purposes, and the
provision of facilities for planning and development.
The protected message service provides acknowledged
message transport between users.
Fig. III 3.2-7…01…AIR CANADA COMPUTING ENVIRONMENT…86…1 …02… …02… …02… …02…
Flexibility in several dimensions
…02…- projected network expansion,
- local area network capability, and
- new equipment types
is supported by the proposed network.
The prjected network expansion is seen as an evolution
progressing in small increments based on a continuous
adaption to the connecting environments by means of
standard expansion elements and modules.
Support of local area includes a capability to incude
the Christian Rovsing local area network, the X-net,
at the travel agents facilities. This net provides
a means for adding circuit switching to the packet
switching facilities implemented by the proposed network.
Addition of new equipment typs is facilitated by the
modular structure of the proposed hardware and software.
Thus, addition of new equipment, whether hosts or
terminals, can take place with a minimum of customizing
and without interrupting the live network activities.
Theproposed backbone network is well suited to the
dynamic environment in which Air Canada operates, an
environment characterised by high volumes of transaction
traffic. An architecture is proposed which essentially
provides Air Canada with open ende growth capability,
an architecture which allows optimal allocation of
services and terminations and which meet current and
projected requirements for connectivity and transaction
volumes; an architecture which enables Air Canada to
make use of maiframe equipment best suited for a given
purpose.
The previous sections presented this general network
architecture and is followed in subsequent subsections
by a detailed mapping of the deliverables proposed
for the Air Canada Data Network.
3.2.4 E̲x̲t̲e̲r̲n̲a̲l̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲s̲
A user of the backbone network is either a host application
or a subscriber using a (terminal) device. An important
function of the proposed network s to establish and
maintain connection between network users. The network
must present a stable environment to the user which
ensures data integrity and provides highly resilient
services for data exchange between users.
The term user as used inthis proposal covers both the
requester of services and the provider of services.
A requester may be a subscriber from his terminal
while a provider may be an internal network service
in the form of PMS or external in the form of a host
applicatio, e.g. ticket reservation. A requestermay
also be a host application, etc. A session describes
the logical connection or the association between two
users of the network.
Privacy is important in a multiservice environment
like the one proposed or Air Canada. The proposed
network implements a high level of protection against
unauthorized disclosure of data and information, based
as it is on a hardware and operating system architecture
derived from well recognized security principles and
mplementations. Higher levels of software reflects
the same discretionary access control and capability
check-out philosophy as implemented by the proposed
operating system.
The Terminal Environment consists of a multitude of
multivendor termina equipment which provide the immediate
environment used by the subscribers of the Air Canada
data services. The proposed network fully supports
the following variety of terminal types:
- CRTs - types 405, 406, 407, 408
- Flight Informatin Displays (FIDs)
- Printers - attached to CRT's
…02……02……02…- teletype model 40
…02……02……02…- ticket printers - DI - AN
…02……02……02…- Extel
- Other devices
…02……02……02…- ASTAC (self ticketing machines)
…02……02……02…- MAC (microcomputer based travel agent
administrativ system)
- IBM 3270 compatible terminals…86…1 …02… …02… …02…
…02…
The backbone network provides connectivity but also
host transparency to the users of the terminal environment.
The proposed network supports multiple applications
running concurrntly between a given user and relevant
hosts. The network establishes and maintains the connection(s)
between user and application(s) on behalf of the user.
The communication management functions are kept transparent
to the user where possible.
The Host environment consists of multiple multivendor processors
which provide the majority of the Air Canada computer provided
services. A major objective in the proposed network is to achieve
an architecture well suited for allowance of existingand new
hosts to be integrated into the Host Environment of the network
without constraints with respect to selection of processor equipment.
The proposed ACDN interfaces a Host Environment consisting of
six hosts implementing the following applicaions:
- Passenger Management (PMH)
- Reservation, VIA (VIA)
- Services Support Host (SUPP)
- Operations (OPNS)
- Cargo (CGO)
- Regional Carriers/
Corporate Services (RCCSH)
IBM and nivac mainframes with installed VTAM and CMS
respectively, may be interfaced and supported as participatory
members by the ACDN. Non IBM systems and IBM systems
not supporting VTAM are interfaced and supported as
attachments to ACDN at present. Ths proposal includes
an offer to develop a participatory interface to Honeywell
DPS/08 computing facilities.
The backbone network establishes and maintains connections
between host applications and other users. It allows
relieving the host of comlex access software occupying
host resources and also the task of network monitoring
and control.
The network includes additional buffering capacity
provided to avoid heavy retransmission activities lasting
a short period of time resulting from host recovery.
This added resilence implies protection of the service
level of other network users. Retransmission caused
by short outages may be avoided for a majority of transactions,
resulting in a lower load for the transport network.
The ACDN interconnects the External Neworks Environment
which consists of a number of national and international
networks. This environment establishes paths between
Air Canada resources of the Host and Terminal environment
and external users and information providing sources,
i.e. reources which are not controlled by Air Canada.
The External Networks Environment consists of the
following data networks:
- SITA
- ARINC
- CNT
The Internal Network Environment covers the present
network excluding those hosts and terminalswhich are
moved to the proposed network, i.e.
…02…- RES Host
…02…- ACNC and connected concentrators and terminals.
This environment plays a major role in the proposed
migration from the existing network to the new network
as presented in this proposl. It provides the means
for enabling migration to take place without interrupting
the services provided to users.
3.2.5 D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲
This section presents the ACDN deliverables in the
context of the general network architecture presented
in the previous section. The hardware elements and
sotware packages of the ACDN are defined and mapped
onto the internal environments of the network architecture.
The proposed Air Canada Data Network might be seen
as basically three environments:
- Network Interface Environment,
- Communicatins Environment, and
- Network Services Environment.
The Communication Environment consists of the Data
Transmission and the Data Link Environment of the general
architecture. The Communications Environment establishes
and maintains basically rror free communication paths
between any two users.
The communication environment implements the layers
1 to 5 in terms of the 7 layer OSI architecture.
The Network Service Environment includes applications
for network management and administrtion as well as
a protected message service. These added value services
are offered to users of the ACDN.
The relation between the internal and the external
environments is depicted in Figure III 3.2-7 "Proposed
Network Architecture". This figre and Figure III
3.2-8 provide the mapping of the hardware and software
which constitute the basic elements of the ACDN.…86…1
…02… …02… …02… …02…
Figure III 3.2-8…01…Proposed Network Architecture
Fig. 3.2-9
Hardware and Software Mapping…86…1 …02… …02… …02… …02…
H̲a̲r̲d̲w̲a̲r̲e̲ ̲M̲a̲p̲p̲i̲n̲g̲
The Network Interface Environment and the Communications
Environment are implemented hardwarewise sharing the
same processing equipment, Nodal Switch Processors(NSPs).
These are co-located with host equipment on the following
three locations: Toronto, Montreal and Winnipeg. The
NSPs are controlled locally by a redundant Nodal Control
Processor (NCP). The term node as used in this proposal
refers to thesystem made up of the NCP and NSPs at
a location.
The nodes provide the termination points to equipment
of all external environments whether in the form of
host data channels or communication lines to terminals
and to other networks. This allows ir Canada to terminate
communication lines of the external networks a the
"closest" node; thus, no particular node is designated
as termination point of e.g. SITA or CNT trafic.
The nodes are mutually interconnected by groups of
56 kbps internoda trunk lines. These trunk lines are
the physical transmission media used by the Communications
Environment.
The Network Service Environment is implemented on a
number of processors each dedicated a specific set
of services.
A Network Control Cnter (NCC) implements the network
control facilities to designated network operators
called supervisors. The NCC is implemented hardwarewise
as part of the NCP of the Toronto Node. A geographical
back-up is likewise proposed as part of the Montrel
node. This results in the increased survivability
of the proposed network.
A Network Management Host (NMH), which provides network
administrative, planning and development facilities,
is implemented by the same type of processor equipment
as al other elements of the network.
An Electronic Mail Host (EMH) implements the hardware
required to provide protected message service (PMS).
The EMH provides a centralized secondary storage for
the PMS traffic in form of mirrored disk equipment,
wile long term storage is provided in form of moveable
disk packs and magnetic tape. The EMH as the NMH is
co-located with the Toronto node.
N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Network Interface Environment is the outermost
layer of the ACDN. It provides a direct physical and
logical interface with the external envionments described
in the previous section. It consists of the interfacing
hardware and software required to support the integration
to external elements; active in form of e.g. participating
hosts providing services and co-operating with the
netwrk, passive in form of e.g. attachments like the
present Air Canada terminal equipment.
The software which implements these capabilities are:
- Host Access Software (HAS)
- External Network Access Software (ENAS)
- Teminal Software (TAS)
- Internal Network Access Software (INAS)
The HAS implements access methods which operate at
mainframe data channel speed while the TAS implements
access methods which operate with communication lins.
The network access software like the TAS, implements
communication line access methods. However, the functionality
between the TAS, ENAS and INAS has led to "integration"
of these into a generalized TAS.
An important role of the HAS and TAS sftware is to
provide the services necessary to allow a user of the
ACDN access to a participating host by making the user
appear to the host system as a valid (host) end user.
This transparency is implemented by transforming,
where applicable, theuser…08…s data to a format more suited
to the host.
The HAS and TAS participates in establishing and maintaining
connections between two users. Both are subdivided
in entities. There will be one such entity for each
type of host or terminal (incluive external and internal
networks). They share the nodal switch processing
equipment.
In summary, the application of a data channel connection
allows an efficient high bandwidth connection to be
established between ACDN and a host processor. Te
integration of external network interface hardware
and software allows Air Canada to terminate external
networks similar to the way terminal equipment is terminated.
In all, the proposed ACDN provides Air Canada with
means of achieving an all-oer cost-effective computing
environment.
C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Communications Environment provides in a sense
the backbone services of the ACDN. It controls the
interconnections between the users and provides he
data transportation facilities. It is implemented by
mutually interconnected Nodal Switch Software (NSS)
executed in Nodal Switch Processors. The NSS implements
a transport network by providing transport, network,
data link, and physical link sevices as presented in
the model for Open Systems Interconnection.
The NSS implements a bridge between the different entities
of the various access software, HAS, TAS, INAS, ENAS.
The NSS appears as a standard transport network to
these higher laers.
The following essential service types are provided
by the NSS to the Network Interface Environment:
- datagram type of service
- switched virtual connection
- permanent virtual connection
- priority
- end-to-end acknowledge
- end-to-ed non-acknowledge
The transportation provided by NSS is carried out by
means of data units in form of packets transmitted
between nodes on internodal trunk groups. The routing
of data is handled by providing each message/packet
with a routing heder and employment of an efficient
routing strategy.
Unrecoverable errors are handed over to network control/system
control software through the layer managers.
N̲e̲t̲w̲o̲r̲k̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
The Network Services Environment provides first of
all global control facilities, secondary added application
services in form of protected messageservice, administrative
billing and planning services and development capabilities.
The network wide resource and control facilities are
provided by the Network Control Software (NCS) of the
NCC supported by the System Control Software (SCS)
locted in the nodes. The SCS implements a local system
wide resource management by centralized algorithms
in the local Nodal Control Processor assisted by layer
wide resource management entities in all of the Processor
Units of a node.
The protectedmessage service is provided by the Electronic
Mail Software (EMS) of the EMH, the administrative
and planning services are provided by the Network Management
Software (NMS) while the development capabilities is
provided by standard development tool, using the processor
equipment of the NMH.
The control software in form of NCS and SCS are special
since neither support transmission of user data, instead
they control the network respectively the local node
configuration. The NCS uses permanetly allocated connections
and resources in the network to control the remaining
part of the network topology. The NCS uses the remaining
software packages to distribute and retrieve configuration
control information and statistics. The NCS plays a
active role in re-establishment of connections between
users (sessions) when such a connection has been temporarily
lost.
The Electronic Nail Software (EMS) implements the
protected message service (PMS). PMS is a store-and-forward
service proided by the network.
Basically EMS maintains the PMS traffic database of
the EMH. It ensures that undelivered messages are retained
for later delivery. Furthermore, it maintains a long
term storage of PMS traffic on magnetic tapes.
3.3 P̲r̲o̲p̲o̲s̲e̲d̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
A common computer architecture is used to implement
all the computerized functions of the ACDN. This includes
two NCCs, three nodes, a Network Mangement Host and
an Electronic Mail Host. The equipment used is based
on the CR80 computer series, designed and manufactured
by Christian Rovsing. The CR80 is configurable and
satisfies the broad range of applications of the ACDN,
present and futue, providing a fault tolerant data-,
packet-, and message switching network.
An overview of the specific system configurations is
shown in Figure III 3.3-1. It reflects the baseline
network for 1985 and illustrates the presence of the
generic nework elements positioned in accordance with
the concept network provided by Air Canada. The proposed
ACDN nodes, NMH and EMH have all been configured as
selfcontained computer systems.
The NCC facility has in the baseline network been integrated
ardwarewise with the Toronto node and a back-up NCC
facility is proposed as part of the Montreal node.
Deviation from the concept network are found in the
areas of the Air Canada Gateway to the existing ACNC
and in the handling of the external neworks, e.g. SITA,
ARINC and CNT.
Figure III 3.3-1
PROPOSED NODE NETWORK
Both of these have for various reasons been integrated
into the nodes.
The Gateway has been integrated into the node due to
its commonality with the TAS package interfacing acces
lines to present types of Air Canada equipment but
also caused by the fairly low amount of traffic anticipated
on this network element. This integration leads to
a more clean migration approach from the initial ACDN
network co-existing with the resent ACNC network to
the baseline ACDN network carrying and terminating
all traffic.
The External Networks termination and handling have
been moved from the EMH for several reasons:
- They present a communications environment and do
as such lgically belong to the terminal access
type of software.
- Apart from the fact that they today carry type
"B" traffic only, there seems in our opinion not
to be a reason for a termination at the EMH.
- Last, but not least, integration of this cpability
into the node allows termination of lines from
these external networks at any of the proposed
nodes.
All critical elements of the ACDN, i.e. the NCC, nodes
and EMH are configured to provide the high level of
fault-tolerance characteristi of a CR80 configuration.
The NMH is basically configured as a simple non-redundant
processor reflecting the fact that this element is
not critical to the operation and functioning of the
proposed network.
Co-located network elements are configuated as a complete
CR80 system with all processors integrated by common
high speed local area suprabusses. Regardless of the
configuration, however, the basic processor, memory
modules, and device controllers are the same. The
detailed configuratins are described in Chapter 5 of
this document.
The CR80 hardware configuration comprises a number
of loadsharing CPU's, grouped together in processing
units, PU's, with up to 5 CPU's per PU and up to 1
Mwords.
Multiple PU's may be interconnectd by a group of 16Mbps
suprabusses. Some PU's may be loadsharing equally,
some may carry out special functions while still others
may be standby units ready to be activated to substitute
currently active PU's.
The hardware is continuously monitored and controlled
via a serial Configuration Control bus extending from
a Watchdog to all switchable and/or monitored assemblies,
such as CPUs,busses, power supplies, and LTU's. To
fully understand the CR80 fault tolerance concept,
the Equipment Characteristics Chapter should be read.
The CR80 architecture allows the open ended growth
in the equipment and hence in processing power, whih
is so crucial in a dynamic transaction oriented environment.
The great flexibility in the hardware configuration
capabilities supports the graceful evolution of ACDN
configurations. As an example, the Gateway equipment
which is being used in te transition phase 1984-1985
may in 1986 be sublimated into the role of terminating
new terminal equipment.
The partitioning of the computer system into a specific
PU configuration does not impact ACDN communications
software. It provides an archtecture which by itself
offers several levels of degraded service should one
or more of the participating processing resources fail.
Furthermore, the redundant hardware design allows even
major configuration changes to take place while the
remainng system is fully operational.
3.4 P̲r̲o̲p̲o̲s̲e̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
This section presents an overview of the proposed software
packages. The detailed description for each package
is found in chapter 6.
The softwar proposed have been collected in a number
of packages. The packages have been based upon func-
tionality and a requirement of a "minimal" interface.
The packages consist of components based on the same
criteria.
Furthermore, the software package play an important
role in providing visibility to the Air Canada's Technical
Management during the implementation phase of the ACDN.
Before embarking on a more detailed description of
the individual packages being proposed, is a mapping
onto theseven-layer Open Systems Interconnection model
presented. Figures 3.4-1 and 3.4-2 depicts this mapping.
The application layer of the OSI model is represented
by the packages implementing value added services to
the network, i.e.
- Network Contol Software
- Network Management Software
- Electronic Mail Software
These services uses the lower layers implemente the
remaining packages to make the services offered available
to all users of the network.
Figure III 3.4-1
ACDN SOFTWARE PACKAGES
Fig. III 3.4-2
ACDN SOFTWARE STRUCTURE…86…1 …02… …02… …02… …02…
The presentation and session layer of the OSI model
is encompassed in the Network Interface Environment
as implemented by the following software packages:
- Host Access Software (HAS)
- Terminal Access Software (TAS)
- External Network Access Software (ENAS)
- Internal Network Access Software (INAS)
An important role of these packages is to implement
the virtual protocols required o map any network user
into a valid host end user.
The transport and network layer of the OSI model are
encompassed by the Nodal Switch Software (NSS) which
furthermore includes the firmware implementing the
data link layer.
The CR80 DAMOS provdes the operating system upon which
the ACDN will be implemented. DAMOS provides all the
general tools for management of the CR80 resources,
CPUs and memory, processors (PUs) and devices. A resource
allocation is implemented which ensures that noprocess
is capable of blocking all available resources managed
by DAMOS. Data integrity and privacy is protected
by kernelised mechanisms.
The Basic Transport Service (BTS) provides the vechicle
for implementing interactive and batch oriented cnnections.
A Basic Datagram Service (BDS) will be implemented
which exploits the CR80 hardware and provides the means
by which high volume transaction oriented connections
are supported. Fundamental to the BDS is that it only
copies data to NSP meory once. The Basic Services
provides a queue driven environment within the normal
DAMOS event driven environment.
The File Management System and Terminal Management
System are used to handle standard files and operator
terminals, e.g. those of he NMH and NCC.
Figure III 3.4-3
ACDN SOFTWARE…86…1 …02… …02… …02… …02…
3.4.1 A̲c̲c̲e̲s̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
To generalize the functionality of the interfaces,
the network provides service to interactive terminals
and supports bulk transfers.
These servies are provided by virtual protocols residing
in the network.
In general the choice of virtual protocols depends
on the services wanted. Apart from the two services
mentioned it is the intention of Christian Rovsing
to implement other necessary irtual protocols on request.
For instance a standardized graphics protocol or a
protocol covering the very high speed classes satellite-communication.
The backbone network proposed provides the following:
- Packet switching (CCITT's X.75) for nterfacing
public networks to ACDN
- Virtual File transfer, (NPL's File Transfer Protocol)
- Virtual Terminal Interaction
(ECMAs Virtual Terminal Protocol)
A virtual protocol is one, which is not used by any
actual equipment attached to thenetwork, at least not
as yet. Actual equipment protocols attached to the
(ACDN), network must be mapped onto the virtual protocol
supported by the network.
Future equipment should be designed to work directly
with the virtual protocols in the nework. By providing
a baseline for future communication via the network,
the virtual protocols are the vehicle for commonality
in the ACDN.
In the selection of the virtual protocols for the network,
one must investigate carefully the trends of th related
standards in the world today. The FTP and the ECMA
VTP presently appear to be the most commonly adopted
in Europe.
Should this not be so for the Canadian environment,
other virtual protocols may be selected for the ACDN.
The File Transer Protocol, FTP, represents a virtual
network protocol for bulk transfers. The implementation
in the backbone network, which is supposed to enable
multihost access to remote facilities like printers
and cardreaders will be the relevant parts of FP-B
(80), also known as blue book (Data Comm. Protocols
Unit, NPL, G3).
The line of services that is foreseen to be adopted
in an initial implementation will be the Host-to-Host
transfer of files at a low level, i.e. printer files,
whereas at a later tage a full implementation including
job-service may be implemented according to existing
standards (ISO/TC97/SC16 N628 or later).
Also, a Virtual Terminal Protocol is proposed for the
ACDN. Several possibilities have been looked at. CCITT
defins a low level virtual terminal standard by the
three standards X.3, X.28 and X.29. Combined these
standards will be a so-called scroll-mode VT offering
user selectable PAD-functions described by a set of
parameters.
However, this will not be suficient to cover the needs
for the terminals to be supported in the backbone network.
Consequently the design will be extended with functions
necessary to cover the level of terminal service needed
for VDU…08…s like UTS 400 and IBM 3270 BSC, the lineof
services supported thus will be as described for the
terminal class "formmode" described in ISO/TC97/SC16
N666 (ECMA/TC23/81/53).
The Network Access Software plays a special role in
this context. As illustrated in Figure III 3.4-1 they
interfce the underlying transport network like the
TAS software. The structure of this access software
is very similar to the TAS as is the role. This explains
the feasibility of integrating the access software
and thus make better usage of the availabl resources
and mechanisms.
The Internal Network Access Software Package implements
the network function for interconnecting the old ACNC
network and the new network. Operating a number of
2.4 or 9.6 Kbps, the Gateway acts against the ACNC
as mutiple ICC's. Against the new data network the
Gateway maps interactive-, printer-, and host-traffic
into the virtual protocols for interactive terminals
and file transfer, respectively.
The External Network Access Software Package plays
a simila role in mapping external connections onto
the internal. The following networks are interfaced:
- ARINC
- SITA
- CNT
3.4.2 N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Nodal Switching software implements the bridging
between the software of the other packages, whether
between entities of the TAS (suppoting a given terminal
type) and entities of the HAS (supporting given host
type) or to a network provided service as implemented
by e.g. EMS in form of protected message service.
The NSS is also the software which directly interconnects
the nodesof the ACDN. The transmission media proposed
are 56 Kbps internodal trunks.
The services provided by the NSS are:
- virtual connection service,
- permanent virtual connection services,
- datagram service.
The CCITT X.25 Recommendation is eployed on all internodal
trunks.
Transport service users are assigned "ports" to access
the transport network at a packet level. Permanent
connections are established for system control purposes
while virtual connections are used for low frequenc
traffic, i.e. interactive and batch type of traffic.
Transaction type of traffic makes use of the datagram
service. Several grades of service are offered to transport
service users:
- priority
- end-to-end acknowledge or not.
The routing implmented by the NSS supports trunk groups.
This includes the ability to have a given message simultaneously
transmitted on several internodal trunks within the
same group.
The switching of data implemented by the NSS depends
on the type of connectio. Transactions are "moved"
in memory by the Basic Datagram Service while other
connections are served by the Basic Transport Service.
This minimizes the delay through the NSP and thus results
in a reduction of switching memory buffers.
The datalink service is implemented in firmware. The
term firmware refers to software residing in the CR80
line terminating unit, the LTU, even though this is
actually software which is downlineloaded at initialization
by the NSP. The firmware includes a uffer manager
and a line handler.
Figure III 3.4-4…86…1 …02… …02… …02… …02…
3.4.3 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Network Control Software (NCS) plays a key role
in maintaining the integrity of the ACDN network. The
capability to support a geographially remote back-up
NCC provides added survivability to the network. The
NCS consists of software components resident in the
Nodal Control Center co-operating with the distributed
System Control Software components of the nodes and
other computer ystems of the network.
Probably the most important task of the NCC is to provide
the operations people with an environment and with
facilities which can assist these people in conducting
a safe network operation.
The facilities made available t these people consist
of colour monitors and operational procedures aimed
at providing static and dynamic information of the
system. The procedures made available to the operators
are based on menu selection and provides the means
for obtaining afast and efficient usage of the network
control and monitoring facilities implemented.
Various graphical presentations are included from a
complete network picture covering hosts, all major
network elements as well as feasible terminal network
prsentations to diagrams presenting resource utilizations.
An important role played by the NCS is that of Definition,
defining external as well as internal resources. The
NCS enables the NMH/NCC operator to assign a unique
logical name to any netwrk resource. However, the allocation
of the network logical identifier is assigned by the
NCS and the operator can not modify this entity; this
is part of the network integrity protection facilities.
The NCS is provided with software facilities wich enables
operators of the NCC and NMH to modify the Global Network
Definition (GND) in a dialogue form. Facilities are
provided which enables files e.g. like those of the
GND to be transferred from the NCC to the NMH and thus
enable configuratio update and check-out to be performed
on a network element operating independent of the live
network.
The Global Network Definition (GND) is broken down
by the NCS to reflect the local configurations and
resources. Thus, the NCS maintains, based on the GND,
a set of definitions fr each of the network systems:
nodes, NCC, NMH and EMH. A copy of the local definitions
is stored on the disk associated with these systems.
This copy is maintained only from the NCC in order
to ensure network integrity.
The network definition may exist in three versions
in the system: Current, previous and under update.
However, only the former two exists in "static" situations
while the "under update" version exist in those periods,
where the NCS is down-line loading a new version.
Facilities are provided to the NCC operators to allow them activation
of any of the three versions. The NCS activates the same version
in all network systems to protect network integrity.
Activation of new versions takes place under local
contro by the SCS. This software is responsible in
protecting existing users which have retained their
old network definitions; this includes implementation
of a version update mechanism which leaves unaffected
sessions undisturbed. Thus, the NCS/SCS laves the
users of the network basicly transparent to system
upgrades.
A provision for assigning time limits to the validity
of given resources is provided. This provision covers
whether the resource goes active at a certain time
or if it is removd after a certain time period (temporary
resource).
The NCS plays a key role in the establishment of sessions.
Two separate classes of sessions are considered:
external and internal.
A network session must be established whenever a user
wantsto establish a connection with a participant of
the network. The NCS is responsible for establishing
this connection and in assigning the proper network
resources. The connection creation is co-ordinated
with the local SCS and check-pointed to dik, both at
the NCC and at the SCS, whether node, NMH or EMH.
Re-establishment of a lost connection caused by e.g.
trunk failure is in the first hand the responsibility
of the SCS. The SCS uses its locally stored session
data in order to provide his service. Failing to re-establish
this connection causes the SCS to inform the NCC operators
via the NCS.
The implementation of a geographical back-up NCC is
based on the implementation by Christian Rovsing on
the Danish FIKS program. A special protocol ensures
synchronization betweenthe two NCC centers. The communication
between the two NCCs is through the transport network
of the ACDN.
Included in this package is also various special test
and trace facilities. These include provision for
monitoring all traffic in and out f a host, a node
or an internodal trunk. They include a possibility
of dumping memory of system elements and displaying
all buffers. The test facilities provided as part of
the ACDN is described as part of Chapter 4.
3.4.4 N̲e̲t̲w̲o̲r̲k̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲o̲f̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Network Management Host functions are included
in the Network Management Software Package system.
It includes the functions necessary for administrating
the network i.e. Subscriber, installation and Billing
Management, Topology Panning, network simulation, statistics
and charging information collection.
Further application subsystems and functions can be
programmed by users via local or remote terminals,
by means of the Software Development Environment supplied.
3.4.5 E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲
The Electronic Mail Software Package implements the
protected message service (PMS) provided by the ACDN.
A central PMS data base was decded to be the most feasible
implementation. Several considerations were taken
into account:
- store-and-forward mechanisms where PMS messages
were stored on each nodal disk leads to longer
response times,
- a solution was considered by which he source node
took PMS responsibility but this leads to a solution
where disks became a critical node element,
- a requirement for unmanned operation of nodes leads
towards a central solution as disks are avoided
for this purpose at the nodes,
- a central EMH leads to one additional hop for PMS traffic
due to the proposed network topology; however, with
the proposed internodal trunk speed of 56 Kbps only
a neglible additional delay is added to the all over
PMS response time.
- the PMS raffic volumes account for 10% of all traffic
of the ACDN; thus, only a minor increase results
on the load of the transport network by a central
solution,
- a requirement for long term storage in the order
of one to two months together with the vlumes of
traffic considered leads to magnitic tape as the
most feasible mass storage for this purpose; this
implies manned operation or additional load of
the transport network when long term storage file
transfer takes place.
The PMS data base mintenance is based on the same technique
as employed on the store-and-forward message switching
developed by Christian Rovsing on the FIKS program.
The EMS employs "core-switching" of PMS transactions,
which results in a reduced load on the disk rives.
PMS traffic is spooled to a fixed head disk, thus avoiding
efficiency derating caused by disk head movements.
A full track is copied at a time to the moveable part
of the disk.
Part of EMS is to provide accountability for messages
in the sense that the EMN is responsible for proper
PMS message delivery once acknowledged is received
by EMH.
A network sesion is established between the EMS and
the proper destinations. The network provides the
same type of service to this type of connection as
to other types.
The System Control Software (SCS) plays an important
role in providing this network servce. The SCS enters
the scene only where the node has been unable to deliver
a PMS message, e.g. broken connection. The SCS keeps
track on undelivered PMS messages and acknowledges
the NCC in such cases. The SCS automatically issues
a retrieval reuest to the EMH once the connection has
been re-established.
Facilities are included as part of the EMS which can
support dedicated EMH operators in correction of faulty
PMS messages via an interactive dialogue. These facilities
are based on substs of the FIKS implementation which
provide similar services.
Statistics collection for this special service is the
responsibility of the Access Software, e.g. TAS Data
are collected and retained as for other sessions.
3.5 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
The results of the performance modelling are presented
this section. It is shown how the proposed ACDN fulfills
the performance requirements of the RFP. Importan design
rationales are presented.
The data provided by Air Canada has been used as input
to derive realistic configurations, both the baseline
as projected 86 thru 91 configurations. Furthermore,
it is shown how the proposed network provides a grwth
capacity beyond the 1991 projected requirements.
The results presented herein have been based on analytic
distributions reflecting specific properties of the
ACDN. Appendix D provides the modelling and analytical
results which form the basis or the performance values
presented in this section.
The following constitute the common assumptions upon
which the performance factors of the ACDN have been
calculated:
- Poisson arrival pattern
- Service times exponentially distributed
- Al servers equally loaded
- All servers have same mean service time
- First-in/First-out dispatching strategy
- No items leave queue
A conservative design policy has been adhered to in
order to provide Air Canada with a sound baseline network
imlementation with built-in investment protection.
No attempts have been made to achieve a minimal hardware
solution which could only satisfy AIR CANADA's current
needs and as such present a risk factor.
The analysis and trade-offs presented in ths section
will be further refined and detailed as part of the
initial Functional Specification phase should Christian
Rovsing be the selected contractor. This critical
project activity must be conducted in close co-operation
with Air Canada personel.…86…1 …02… …02… …02… …02…
3.5.1 N̲o̲d̲e̲ ̲M̲o̲d̲e̲l̲l̲i̲n̲g̲
The nodes of the ACDN provide the termination of connected
hosts and access lines to terminal concentra-
tors. This section presents the results of the perfr-
mance analysis for the proposed nodes in terms of volume
capacities and transfer times. The rationale for the
design which implements these functions is presen-
ted to provide the background required to evaluate
the presented information. The odelling presented covers
the RFP requirements as well as the new Corporate Service
Information Host in Dorval.
3.5.1.1 E̲n̲d̲-̲t̲o̲-̲E̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲
The end-to-end response times expected for the different
types of ACDN traffic are summarized below
Response TYPE A TYPE B RCCSH
time (sec) Req. ACDN Req. ACDN Req.
ACDN
average - 1.2 - 2.1 -
6.0
85% 2.5 1.7 5 2.5 -
10.8
95% 2.7 - 3.5 -
17.4
Excluding the contributions from resources outside
ACDN, i.e. terminal and host environments leads to
the following ACDN round trip delays:
Round Trip Type A Type B RCCSH
(sec)
averag .2 .5 .7
85% .3 .6 .8
95% .5 .8 1.0
3.5.1.2 P̲r̲o̲c̲e̲s̲s̲o̲r̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
The processing time required to switch a transaction
is:
15.4 msec.
Thus, the switching capacity of a Nodal Switch Pro-
cessor (SP) equipped with four CPUs is:
200 packets/sec.
The CPU utilization upon which the proposed ACDN configurations
are based is:
61 per cent
This utilization caters for the additonal handling
required by the proposed ACDN virutal protocl handling,
emulation, acknowledgements and network control.
Furthermore, the choice of this low utilization factor
reflects an intent to provide Air Canada with a net-
work with built-in allowance for later increases in
processing requirements.
Thus, the capacity of each NSP equipped with four equal
CPUs is
100 incoming transactions/sec.
whether received from a terminal or a host.
This leads to a total maximum capacity of an ACDN node
of:
1100-1200 incoming transactions/sec
The maximum capacity corresponds to more than the double
of the projected 1991 transaction volume. Note, however,
that this capacity may be increased by a factor of
three to four by a cluster of four co-located nodes.
3.5.1.3 M̲e̲m̲o̲r̲y̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
The buffer capabity required in order to support the
designed transfer rate per Nodal Switch Processor is:
120 buffers.
The basic assumption behnd this is that each buffer
holds one transaction or that three buffers may hold
one RCCSH interaction. Secondly, it reflects the traf-
mix represented by:
- 4 internodal trunks
- 60 access lines
together with a requirement that retransmision caused
by "buffer unavailable" should be required for less
than .1 per cent of all transactions.
The above number of buffers excludes any buffers permanently
allocated for input handling for the purpose of reducing
input processing time. Furhermore, this capacity does
not properly reflect the impacts of the proposed type
"B" handling. The proposed buffer capacity has been
sized to include this handling.
The proposed NSPs are for all proposed ACDN nodes provided
with buffer capacity n excess of the minimum required.
Generally, all memory space which is not permanently
allocated to programs, data, and tables is allocated
as buffers. This leads to a buffer utilization of:
25 per cent
for the typical NSP.
The reason fo providing this additional memory capacity
has been a trade-off of price versus the additional
benefits derived:
- Additional buffer capacity may be used to retain
type "B" traffic for periods where an access line
is temporarily out-of-service.
- The additirnal nodal buffer capacity may be used to
buffer transactions to applications which are temporarily
out-of-service.
The aim is twofold. Firstly, to remove the subscriber's
awareness of short variations in Air Canada…08…s computing
resources; secondly, to protect the internodal trunk
network againt excessive load conditions caused by
retransmissions and thus avoid influencing the service
provided to other users.
The following summarizes the memory mapping of the
exemplified NSP:
Programs
- DAMOS 43K - Application
103K
Data
- DAMOS 93K
- Application
o tables 10K
o 3000 CRT 48K
SCBs, 2 each 72K
o 1500 other sub's 24K
SCB's, 1 eah 1̲8̲K̲ 172K
- Buffers
o 180 x 64 bytes 6K
o 540 x 512 bytes ̲1̲3̲8̲K̲ ̲ 1̲4̲4̲K̲
5̲1̲2̲K̲
3.5.1.4 I̲n̲t̲e̲r̲n̲o̲d̲a̲l̲ ̲T̲r̲u̲n̲k̲ ̲U̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲
The utilization on the internodal trunks has been chosen
as:
75 per cent
This high utilization factor was decided upon taking
the folloing into consideration:
- minimize number of internodal trunks
- evaluate additional delay caused by high utilization
versus transmission and queueing delays on access
lines
- usage of trunk groups advantages due to the better
…02…service which esults from a multiserver environment.
The effective data utilization has been estimated as:
81.5 per cent.
This utilization factor excludes the ACDN communication
header, internal end-to-end acknowledgements, network
control traffic and dos as such only include the data
entering the ADCN.
The communication header has for sizing purposes been
set to 20 bytes and excludes a trailer of 3 bytes.
This accounts for about half of lost bandwidth.
Furthermore, it has been assumed that th internal network
control traffic is on average 200 bytes.
3.5.2 G̲a̲t̲e̲w̲a̲y̲
The Air Canada "Gateway" has been included as part
of the Toronto node by provision of dedicated ACNC
LTUs.
The total bandwidth proposed between the existing ACNCand
the ACDN is:
48 Kbps.
The bandwidth has been achieved by 5 LTUs each emulating
4 normal 2400 bps access lines which provide a transfer
capacity of:
50K transactions per peak hour.
This traffic corresponds to 10 per cent of the capacty
of a fully equipped NSP.
The integration of the Gateway into the node leads
to a migration plan which is capable of being adjusted
to substantial variations in workloads.
The proposed "Gateway" capability has its response
time characteristic in common with other node elements.
Thus, the major elements in end-to-end response time
for transactions which are exchanged between the old
and the new network are:
1 Access network delays
2 Nodal delays
3 Internodal trunk delay
4 Gatewaytrunk delay
5 ACNC delay
6 Host delays
Elements 1,5 and 6 corresponds to the delays existing
at present, while 2, 3, and 4 are additional delays.
The gateway trunk will represent the major contribution
in additional delay irrespective of seleted trunk speed.
Selection of e.g. 2400 bps would lead to additional
response time of average 1.2 sec. (95%: 2.4 sec.) while
9600 bps leads to average .4 sec. (95%: .7 sec.).
3.5.3 E̲M̲H̲ ̲M̲o̲d̲e̲l̲l̲i̲n̲g̲
The EMH provides a central store-and-forward switching
service of the ACDN. This section presents the results
of the performance analysis of the proposed EMH n terms
of traffic volume capacities and transfer time. The
rationale for the design which implements this function
is presented to provide the background required to
evaluate the presented information.
The EMH implements a design which balances he performance
of the utilized storage media:
- high speed main memory
- high speed fixed head disk storage
- medium speed moveable head disk storage
- low speed long term magnetic tape storage
The actual EMH equipment will be tailored to met projected
type "B" traffic volumes. Below are the CPUs and disk
paths required to fulfill the projected growth:
Year Peak hour 10…0e…3…0f… transactions
CPU MDD 300Mb
volumes disk disks
to EMH all (Mbytes) req'd pro'd paths
85 38.9 87.5 156 1 2 1 1
86 42.8 96.5 172 1 2 1 1
87 47.2 106.2 189 2 2 1 1
88 51.8 116.6 208 2 2 1 2
89 57.2 128.9 228 2 2 1 2
90 62.6 141.1 251 2 2 1 2
91 69.1 155.5 26 2 2 1 2
* mirrored
The bandwidth of one CPU, i.e. the maximum number of
PMS transactions one CPU can handle in a given CPU
is:
…02……02…55 PMS trans/sec
To allow for acknowledgement handling, fixed to
oveable head operations, checkpointing, retention of
undelivered transactions, manual recovery of garbled
messages, the design capacity per CPU is decided as
50% of the bandwidth or
…02……02…100,000 PMS trans/peak-hour.
Each Electronic Mail Processo (EMP) will be equipped
with from 2 to 3 CPUs as required to support the allocated
traffic load. The EMPs are each provided with 512 Kwords
of memory; memory which is utilized as that of the
Nodal Switch Processors.
The bandwidth to the fixed hea of the proposed disk
is:
…02……02…236 PMS trans/sec.
The same rationale as that used for the CPU capacity
has been used in deciding the design capacity of the
disk which results in:
…02……02…425,000 trans/peak-hour.
The capacity of the fixed head storag of 900 Kbytes
corresponds to:
…02……02…30 sec
of design capacity traffic while the moveable head
surface of approximately 60 Mbytes corresponds to:
…02……02…35 min.
Main memory buffer capacity is used to increase the
efficiency of CPUs and minimize the uage of disk storage
other than for write.
Transactions which require PMS service by the ACDN
are transmitted to the EMH. The EMH retains a copy
of the message in a main memory buffer while a mirrored
write operation is conducted to the fixed headportion
of the disk storage.
The successful storage to disk results in acknowledgement
to the PMS requester and forwarding of the copy retained
in memory to the transport network which takes responsibility
for proper delivery.
As a basis for the modelling activity it has been assumed
that 90% of all original PMS transactions are handled
this way. The buffer storage of an EMP supports storage
of the trafic equivalent to several seconds (approx.
55 PMS transactions per EMP).
The remaining 10% will be retrieved from the fixed
head part of the disk storage.
Retransmission of undelivered messages and retrieval
from the moveable head part of the dik storage (or
from magnetic tape) has for sizing purposes been assumed
to be 10% of the basic PMS traffic.
Additional performance improvements of the bandwidth
will be implemented by collecting up to three PMS transactions
before the actual writeoperation is performed. The
write operation to fixed head takes on average 8.3
msec, max. 16.7 msec. This, together with the applied
write strategy leads to the high transfer rates predicted
for the EMH.
The EMH transfer time is determined by a cntribution
from three components:
- delay caused by storage strategy
- write to/retrieval from disk
- switching to node/session handling
The major contributor is the delay caused by the applied
storage strategy. However, this delay will neverexceed
the time taken to perform three consecutive PMS writes.
This leads to an EMH transfer time which for the majority
of all PMS transactions does not exceed:
…02……02…200 msec.
3.5.4 R̲e̲l̲i̲a̲b̲i̲l̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲
o The proposed ACDN provides Air Canada with a highly
…02…resilient network. Surviveability has been increased
by provision of geographical backedup network control
facilities. Protection against single point failures
is offered in the form of a fault-tolerant computer
architecture. The distributed architecture offered
provides additional advantages in form of graceful
degradation.
It shoud be noted that the results presented in this
section represents an analysis which has been based
on RMA requirements far more stringent than those presented
in the RFP.
a. I̲n̲d̲i̲v̲i̲d̲u̲a̲l̲ ̲S̲u̲b̲s̲c̲r̲i̲b̲e̲r̲
The RMA analysis for the individual subscriber
hs assumed a dual host in order to isolate the
effect of this element.
MTBF…0f…subscriber…0e… = 3.5 years
MTTR…0f…subscriber…0e… = 28 min
Availability…0f…subscriber…0e… = 99.9985%
The RMA analysis implies that a pecific subscriber
every 3.5 years will be without service from the
ACDN for a period of 28 min.
b N̲e̲t̲w̲o̲r̲k̲
The following RMA requirements are stated as those
which result in the network being considered up:
1. Network capable to provide ful service to a̲l̲l̲
connected subscribers (except 4, below).
2. Host connections assumed dualized to remove
this factor.
3. Internodal trunks backed-up by rerouting.
4. At most one group of two access lines per NSP
without service.
5. All NSPs assumed worst case NSPs, i.e. with
36 access lines.
6. Only maximum configured nodes assume, i.e.
with NSPs).
The results which apply to the network subject
to the above assumptions are as presented below:
MTBF…0f…ACDN…0e… = 8900 hours
MTTR…0f…ACDN…0e… = l5 min
Availability = 99.9972%
While the individual nde (maximum configuration)
is
MTBF…0f…node…0e… = 3.l years
MTTR…0f…node…0e… = l5 min
Availability = 99.999l%
c E̲l̲e̲c̲t̲r̲o̲n̲i̲c̲ ̲M̲a̲i̲l̲
The RMA analysis results which apply to the Electronic
Mail Host are:
MTB…0f…FENH…0e… = l4 years
MTTR…0f…EMH…0e… = 48 min
Availability = 99.9995%
To the above should be noted that it reflects the l99l
EMH configuration and that the disks storages represent
the major factor to the stated EMH failure rates.
3.6 B̲a̲s̲e̲l̲i̲n̲e̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲ ̲a̲n̲d̲ ̲P̲r̲o̲j̲e̲c̲t̲e̲d̲ ̲G̲r̲o̲w̲t̲h̲
3.6.1 B̲a̲s̲e̲l̲i̲n̲e̲ ̲C̲a̲p̲a̲c̲i̲t̲y̲
The proposed baseline ACDN has been sized to handle
the anticipated l985 load. The following summarizes
the poposed capacities by location:
Toronto Montreal Winnipeg
l000 Transactions/hour 575 549
918
Host Connections 2 2
2
Internodal Trunks 3+2 2+3 3+3
ICC Access Lines 69 81
58
RCCSH Access Lines 0 33
8
3.6.2 P̲r̲o̲j̲e̲c̲t̲e̲d̲ ̲G̲r̲o̲w̲t̲h̲
The baseline ACDN configurations will be sized to handle
the projected capacities.
The projected volumes and required network capacity
are summarized belw:
a T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲/̲s̲e̲c̲.̲
The projected peak hour transaction volume per
sec. per node is:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TRANSACTIONS/SEC
YEAR TOR MTL WPG
84 137.0 130.8 218.7
85 159.7 152.5 255.0
86 185.4 177.0 296.0
87 203.9 194.7 325.6
88 224.3 214.2 358.2
89 246.8 235.6 394.0
90 271.4 259.1 433.4
91 298.6 285.1 476.7
The above represents the total incoming transaction
volume to nodes generated by resources outside the
node.
b. I̲n̲t̲e̲r̲n̲o̲d̲a̲l̲ ̲T̲r̲a̲f̲f̲i̲c̲
The projected internodal peak hour traffic is:
KBPS INTERNODAL TRUNKS
YEAR T-M T-W M-W T-M T-W M-W
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
84 28.4 81.8 79.6 .8 2.4 2.3
85 33.2 95.4 92.8 1.0 2.8 2.7
86 38.5 110.7 107.7 1.1 3.2 3.1
87 42.3 121.8 118.5 1.2 3.6 3.5
88 46.6 133.9 130.3 1.4 3.9 3.8
89 51.2 147.3 143.3 1.5 4.3 4.2
90 56.4 162. 157.7 1.6 4.7 4.6
91 62.0 178.3 173.5 1.8 5.2 5.1…86…1
…02… …02… …02… …02…
The projected internodal traffic has been derived using:
1. the projected transaction volume,
2. the projected length of transactions, type by type,
3. assuming a communicatons header of 20 bytes plus
trailer of 3 bytes,
4. assuming l0% network control, acknowledge traffic
with average length corresponding to that of other
traffic,
5. a trunk utilization of 75% has been used as baseline
to establish the required nmber of internodal trunks.
c Access Lines
YEAR ACCESS LINES IBM LINES
T M W T M W
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
84 59 69 50 0 30 7
85 69 81 58 0 33 8
86 81 95 68 0 34 9
87 89 104 74 0 38 9
88 98 115 82 0 42 10
89 107 126 90 0 46 11
90 118 139 99 0 50 13
91 130 153 109 0 55 14…86…1 …02…
…02… …02… …02…
3.6.3 B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲s̲
This section presents the year by year block diagrams
which constitute both the baseline but also the projected
growth.
Only major network elements have ben included:
o Network Management Processor (NMP)
o Nodal Control Processors (NCP)
o Nodal Switching Processors (NSP)
o Electronic Mail Processors (EMP)
o Channel Units
Figure III 3.6-1…86…1 …02… …02… …02… …02…
Figure III 3.6-2…86…1 …02… …02… …02… …02…
Figure III 3.6-3…86…1 …02… …02… …02… …02…
Figure III 3.6-4…86…1 …02… …02… …02… …02…
3.7 T̲e̲l̲e̲c̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲s̲
Recently Christian Rovsing's maintenance subcontractor
CNCP Telecommunications, responded to an Air Canada
Request for Information (RFI). Their response t the
RFI dated December 15, 1980 is included in its entirety
in this proposal as Appendix E.
Christian Rovsing feels this document provides Air
Canada with sufficient details on CNCP's existing network
services and offerings, as well as their plns for the
future, to enable Air Canada to plan for a total solution
to their communication requirements.
3.8 O̲p̲t̲i̲o̲n̲s̲
o The hardware and software structures fully support
openended growth beyond the projected backbone
network expansion.
Potential growth areas are:
- Internodal Meabit Trunk Capacity (2Mbit(s)
- Voice Switching through the ACDN
- Internodal Megabit satellite links
- Front End Processor connections to Host Access
Network
- Videotex
- Telefax
- Encryption
The (Internodal) trunk capacity in the megabi range
will be necessary both for the connection of the Passenger
Management System and for the Host-to-Host links in
the Host Access Network.
The CR80 module, the STI, presently interfacing to
the 16 Mbps SUPRA Bus and the 1.8 Mbps TDX bus, can
e used as the interface to such megabit communication
lines, together with the appropriate adapter.
This also supports megabit satellite loops, when needed,
since the STI can have at its disposal up to 1 Mega
words; and large buffering capacity ad a selective
retransmission function are needed in order to provide
efficient transmission over the long-delaying satellite
hops.
Either based upon conventional digitized voice transmission
using standard 64 Kbps per channel or on the latest
comressed-coding transfer chips, by which voice channels
can be as narrow as 240…0e…o bps, the Air Canada Data Network
Equipment is well suited to include such types of traffic
too. This is indicated as a Common Branch Exchange
and as an automated offic processor with a local network.
Videotex and Telefax might also be attachable, directly
or through other public networks.
These examples were intended to illustrate the residence
of the CR80 System Approach:
The system is balanced, i.e. it des not create inhibiting
bottlenecks, when growth occurs.
Presently foreseen are the needs for encryption facilities.
Such implementations will benefit from our significant
experience in this field.
Soon to come may be the need for futher Host Access
Subsystems which are part of the Host-Access Network.
The CR80 system concept is well suited for such applications,
as shown with the UNIVAC and IBM host Example offered,
and we look forward to supplying parts of the Host
Access etwork as amendments to the backbone Network.
For future efficient interconnections of the ACDN and
public data networks, the X.75 Gateway may be of interest.…86…1
…02… …02… …02… …02…
3.8.1 V̲i̲d̲e̲o̲t̲e̲x̲
Christian Rovsing is in a position to offer Videotex
as an added value service to the proposed ACDN. This
product could be implemented as part of the proposed
Elecronic Mail Service.
VIDEOTEX, also known as Viewdata, is a facility for
retrieving information from computer data bases. The
information is stored in "pages" in the VIDEOTEX system
or may optionally be retrieved from external data bases.
VIDEOTX adds, to a data processing environment, the
capability of using low-cost and standardized terminals
to interact with different data bases in a user-oriented
way.
Applications for VIDEOTEX are virtually inlimited.
Here are a few examples:
o Nws Media
- news briefings
- weather forecasts
- restaurant guides
- going out
o Travel and Tourist Information
- time tables, local and global
- information on destinations, domestic and foreign
- local transportation schedules
-local entertainment guides
o Advertising
o Banking
- account inquiries
- funds transfer
- bill payments
- product/service manuals
- financial news service
- calculations
The VIDEOTEX product has been delivered by Christian
Rovsing to the Danish Tele Administrations implemented
on the CR80 computer system.
VIDEOTEX offers the following capabilitis:
- Retrieval of VIDEOTEX images in a CR80 database
- Generation/modification of VIDEOTEX images
- Maintenance of user catalogue
- Provision for generation of users in user groups
- Maintenance of password
- Message service
- Generation ofprimary keywords
User terminals acquire access to the CR VIDEOTEX system
by means of call on the public telephone network. This
facility could be useful as it could provide a means
of establishing a "public" entry point to ACDN value
added servics.
The user of this could be a subscriber external to
the ACDN who could dial this service. A normal television
set modified with low-cost circuit board as a terminal
and provided with a low-cost modem is what that subscriber
needs to use in thisfacility.
A logon image is presented to the user when he has
acquired access to the system. The user has to key
in his user number and associated password. The user
may choose individual VIDEOTEX applications once the
authentication has been succ
