⟦15ee765f4⟧

WangText

…00……00……00……00……00……1b……0a……00……00……1b……0b……1b……05……1b……07……1a……0d……1a……06……19……08……19……09……19……00……18……08……18……09……18……00……17……0a……17……02……16……08……16……00……16…
…16… …15……0d……15… …15……05……14……0b……14……0f……14……06……13……09……13……01……13… …12……0d……12……0e……12… …11……0d……86…1 …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02… …02…

CHAPTER 3

Page

DOCUMENT III          TECHNICAL PROPOSAL      Oct. 8,
1981
Rev.:Mar. 1, 1982

LIST OF CONTENTS                          Page

3.           PROPOSED SOLUTION ..............................
    3

3.1          Introduction ...................................
    4

3.2          Proposed Technical Solution ....................
    6

3.2.1       Scope of Air Canada Data Network ...............
    6
3.2.2       Functional Overview ............................
    8
3.2.3       External Environments ..........................
  11
3.2.4       Proposed Network Architecture ..................
  14

3.2.4.1     Network Interface Environment ..................
  17
3.2.4.2     Communication User Environment .................
  18
3.2.4.3     Transmission Environment .......................
  22
3.2.4.4     Data Link Environment ..........................
  23
3.2.4.5     Network Service Environment ....................
  24
3.2.4.6     Network Architecture Realisations ..............
  25

3.2.5       Deliverables ...................................
  26

3.3          Proposed Hardware Equipment ....................
  34

3.4          Proposed Software Packages .....................
  38

3.4.1       Access software ................................
  42
3.4.2       Nodal Switching Software .......................
  45
3.4.3       Network Control Software .......................
  46
3.4.4       Network Management Software ....................
  50
3.4.5       Electronic Mail Software .......................
  51

3.5          Performance ....................................
  53

3.5.1        Node Modelling .................................
  54

3.5.1.1     End-to-End Response Time .......................
  54
3.5.1.3     Memory Utilization .............................
  56
3.5.1.4     Internodal Trunk Utilization ...................
  58

3.5.2       Gateway ........................................
  59
3.5.3       EMH Modelling ..................................
  60
3.5.4       Reliability and Availability ...................
  63

3.6          Baseline Capacity and Projected Growth .........
  65

3.6.1       Baseline Capacity ..............................
  65
3.6.2       Projected Growth ...............................
  66
3.6.3       Block Diagrams .................................
  68

                            3.8         Options ........................................
  74

3.8.1       Videotex .......................................
  76

                            3.            PROPOSED SOLUTION

…02……02……02…To the extent that Air Canada is embarking on

…02……02……02…establishing a network base for the 1980s with the

…02……02……02…full knowledge of the positive impact this will

…02……02……02…have on Air Canada|s operations, services to the

…02……02……02…passengers and to the {irline industry|s commercial

…02……02……02…infrastructure, we have presented in this chapter

…02……02……02…our solution in the context of a broad perspective

…02……02……02…over the trends in data communications industry in the

…02……02……02…19B0s.

…02……02……02…The key themes behind our proposed solution are:

…02……02……02…High availability:          Through fault tolerance and

…02……02……02……02……02……02……02……02…redundant hardware and throug

…02……02……02……02……02……02……02……02…a unique network control

…02……02……02……02……02……02……02……02…philosophy.

…02……02……02…Granular Expandability:   Through a scheme that

…02……02……02……02……02……02……02……02…explo*ts multiprocessing

…02……02……02……02……02……02……02……02…configuratons and

…02……02……02……02……02……02……02……02…distributed functions.

…02……02……02…Investment Protection:     Through a networking scheme

…02……02……02……02……02……02……02……02…that supports heterogenous

…02……02……02……02……02……02……02……02…hosts, data transport

…02……02……02……02……02……02……02……02…services, terminal types

…02……02……02……02……02……02……02……02…and a networking schypes

…02……02……02……02……02……02……02……02…based on available

…02……02……02……02……02……02……02……02…standards.

…02……02……02…Subscriber services:       By exploiting available

…02……02……02……02……02……02……02……02…standard software and

…02……02……02……02……02……02……02……02…firmware for host support

…02……02……02……02……02……02……02……02…and terminal devices

…02……02……02……02……02……02……02……02…support.

                            3.1           Introduction

…02……02…***************

…02……02…The scope of this chapter is to convey to the

*** LINE REJECTED ***

…02……02…Christian Rovsing to meet the functional requirements

…02……02…contained in the Air Canada RFP.

…02……02…This chapter also serves to provide a high level

…02……02…breakdown of the proposed Air Canada Data Network

…02……02…including the associated rationale. The breakdown

…02……02……02…is covered in terms of hardware and software

…02……02…architectures.  The software is presented in terms

…02……02…of the 7-layer OSI architecture.  Additionally,

…02……02…this chapter presents the predicted performance and

…02……02…response times.

…02……02…The proposed solution is presented in a broad context

…02……02…in section 3.2.   Subsection 3.2.1 provides the scope

…02……02…of the backbone network as preceived by Air Canada

…02……02…while subsection 3.2.2 gives a functional overview on

…02……02…the proposed Air Canada Data Network, while

…02……02…subsection 3.2.3 defines and presents the external

…02……02…|environments| to which the proposed Air Canada Data

…02……02…Network provides service.

…02……02…Subsection 3.2.4 presents the proposed network

…02……02…architecture by covering the internal environments,

…02……02…the mapping and their interrelation. The mapping of

…02……02…the deliverable hardware and software on the

…02……02…environments of the architecture is provided in

…02……02…subsection 3.2.5.

…02……02…Section 3.3 provides the high-level break-down of the

…02……02…hardware.

…02……02…The software functional basis and structure is

…02……02…presented in section 3.4.  This section covers

…02……02…interfaces to the backbone network from users, i.e.

…02……02…from host computers, other networks, via the Gateway

…02……02…to the existing network, and to terminal equipment.

…02……02…Results of the performance analysis, i.e. response

…02……02…times and capacities, are presented,in section 3.5.

…02……02…Finally, section 3.6 discusses the projected growth

…02……02…capabil*ties of the network with respect to capacity

…02……02…and functionality while 3.8 discusses potential

…02……02…growth areas.

3.2 Pro*****************************

…02……02……02…*********************************************************************

Figure 3.2-1

                            The general purpose computer
facilities may include
some software for supporting remote terminals and
associated communication procedures.  ACDN as
conceived and presented in this proposal excludes all
such facilities in their entirity.

The implied transparancy in the ACDN is that an*aced
to ACDN.

It is our conviction that in the 1980s there is no
real need to distinguish between terminals and
computing facilities, and as such we use the words
synonymously.

The ACDN supports two distinct interfacing mechanisms
which are described below.

a  AttachmentstoACDN

…02…Any computing facility can be interfaced to ACDN as

…02…an |attachment|.  Attachment implies that a computin

*** LINE REJECTED ***

…02…terminals with predetermined characteristics.

…02…Attachment implies that a computing facility so

…02…interconnected does not play any role in providing

…02…and controlling the resources made available to

…02…the whole spectrum of ACDN users.

b. Partici****************

*** LINE REJECTED ***

…02…application resources contained in that computing

…02…facility are made available to all ACDN users.

…02…The control functions in the ACDN monitors the stat

…02…of the application resources in each participant

…02…member and maintains the validity of the resource

…02…status on a network wide basis.  Such participants

…02…are referred to as |HOST| synonymously.

                            3.2.2         Functional Overview

…02……02……02……02……02……02…-

…02……02…The proposed network provides the means for

…02……02…integrating present as well as future computer and

…02……02…terminal facilities assigned to the following

…02……02…environments:

…02……02……02…-  Host Environment

…02……02……02…-  External Network Environment

…02……02……02…-  Internal Network Environment

…02……02……02…-  Terminal Environment

…02……02…The users, host applications and terminal operators,

…02……02…uses a combination of the facilities implemented in

…02……02…the Host, Network, and Terminal Environments

…02……02…together with those of the ACDN.  The ACDN

…02……02…interconnects the external environments and provides

…02……02…a level of integration which makes the actual network

…02……02…topology and application allocation transparent to

…02……02…the user. This is illustrated in Figure 3.2-2 "Air

…02……02…Canada Data Network Environment".   Each of these

…02……02…environments is described in more details in the

…02……02…next section.  The remainder of section summarizes

…02……02…the services and capabilities of the ACDN.

…02……02…In addition to the packet switch based services which

…02……02…implement interconnection between users, the network

…02……02…itself provides the following services:

…02……02……02…-  Network Control

…02……02……02…-  Network Management

…02……02……02…-  Protected Message Service

…02……02…The network control services are provided to

…02……02…designated personnel, network supervisors and field

…02……02…technicians.  These services provide a centrally

…02……02…controlled environment which protects the

…02……02…integrity of the network and ensures consistent

…02……02…service to all users.

…02……02…The network management services covers collection of

…02……02…statistical information for billing purposes, the

…02……02…provision of facilities for planning and development.

…02……02…The protected message service provides acknowle*ged

…02……02……02…message transportation between users.

Figure 3.2-2

                            Flexibility in several dim*nsions

…02…-  projecwed networs expansion,

*** LINE REJECTED ***

is supported by the proposed network.

The projected 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
include the Christian Rovsing local area network,
the X-net, at the travel agent|s facilities. This net
provides a means for adding circuit switching to the
packet switching facilities implemented by the proposed
network.

Addition of new equipment types is facilitated by the

*** LINE REJECTED ***

hosts or terminals, can take place with a minimum of
customization and without interrupting the live
network activities.

The proposed 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
ended growth capability, an architecture which allows
optimal allocation of services and terminations and
which meet current as projected requirements to
connectivity and transaction volumes, an architecture
which enables Air Canada to make use of mainframe
equipment best suited for a given purpose.

The following sections present this general network
architecture followed by a detailed mapping of the
deliverables proposed for the Air Canada Data
Network.

                            3.2.3        External Environments

…02……02……02…A user of the backbone network is either a host

…02……02……02…application or a subscriber using a (terminal)

…02……02……02…device.  An important function of the proposed

…02……02……02…network is to establish and maintain the connection

…02……02……02…between subscriber and application on behalf of and

…02……02……02…transparent to the user.  The network must present a

…02……02……02…stable environment to the user which ensures data

…02……02……02…integrity and provides highly resilient services for

…02……02……02…data exchange between users.

…02……02……02…The term user as used in this proposal covers both

…02……02……02…the requester of services and the provider of

…02……02……02…services.  A requester may be a subscriber from his

…02……02……02…terminal while a provider may be an internal network

…02……02……02…service in form of PMS or external in form of a host

…02……02……02…application, e.g. ticket reservation.  A requester

…02……02……02…may also be a host application, etc.  The session

…02……02……02…describes the logical connection and associated

…02……02……02…associations between two users of the network.

…02……02……02…Privacy is important in a multiservice environment

…02……02……02…like the one proposed for Air Canada.  The proposed

…02……02……02…network implements a high level of protection

…02……02……02…against unauthorized disclosure of data and

…02……02……02…information, based as it is on a hardware and

…02……02……02…operating system architecture derived from well

…02……02……02…recognized security principles and implementations.

…02……02……02…Higher levels of software reflects the same

…02……02……02…discretionary access control and capability

…02……02……02…check-out philisophy as implemented by the proposed

…02……02……02…operating system.

…02……02……02…The Terminal Environment consists of a multitude of

…02……02……02…multivendor terminal equipment which provide the

…02……02……02…immediate environment used by the subscribers of the

…02……02……02…Air Canada data services.  The proposed network fully

…02……02……02…supports the following variety of terminal types:

…02……02……02…-  CRTs      - types 405, 406, 407, 408

…02……02……02…-   Flight Information Displays (FIDs)

…02……02……02…-  Printers - attached to CRT|s

…02……02……02……02……02…- teletype model |0

…02……02……02……02……02…- ticket printers - DI - AN

…02……02……02……02……02…- Extel

…02……02……02…-  Other devices

…02……02……02……02……02…- ASTAC (self ticketing machines)

…02……02……02……02……02…- MAC   (microcomputer based travel agent

…02……02……02……02……02……02……02…administrative system)

…02……02……02…-  IBM 3270 compatible terminals

                            The backbone network provides
connectivity but also
host transparency to the users of the terminal
environment. The proposed network supports multiple
applications running concurrent 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 was to achieve an
architecture well suited for allowance of existing
and 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 seven hosts implementing the following
applications:

-  Passenger Management    (PMH)

-   Reservation, VIA         (VIA)

-  Corp Services Support   (CORP)

-  Maintenance/P & S        (MTCE)

-  Operations                (OPNS)

-  Cargo                      (CGO)

-  Corporate Services      (CSIH)

IBM and Univac 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.
This 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 relievin*ost resources but also the
task of network monitoring and control.

                            The network includes additional
buffering capacity
provided to avoid heavy retransmission activities
resulting from host recovery lasting a short period
of time.  This added resilience 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 of the transport network.

The ACDN interconnects the External Networks
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. resources 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 terminals which
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 *he proposed
migration from the existing network to the new network
as presented in this proposal.   It provides the means
for enabling migration to taRe place without
interrupting the services provided to users.

                            3.2.4        Pro*******************************

…02……02…This section presents the proposed Network

*** LINE REJECTED ***

…02……02…services provided by these layers are described, in

…02……02…particul{r the services provided to the users in the

…02……02…external environments defined in the previous

…02……02…section.  The hardware and software which constitute

…02……02…the deliverables to Air Canada are described in the

…02……02…subsequent section 3.2.5.

…02……02…In the context of the scope of the ACDN a set of

…02……02…interrelated |environments| c{n be identified as the

…02……02…component parts of the general network architecture,

…02……02…to which ACDN relates.

…02……02…Essential to the proposed architecture is that

…02……02…entities communicate with corresponding remote

…02……02…entities in the same environment.

…02……02…The following five internal environments are the

…02……02…component parts of the general network architecture:

…02……02…-  Network Services Environment,

…02……02…-  Network Interface Environment,

…02……02…-  Communications User Environment,

…02……02…-  Data Transmission Environment,

…02……02…-  Data Link Environment,

…02……02…The Network Interface Environment provides the

…02……02…physical and logical interface wit* attachments and

…02……02…participants to the external environment.  It relieves

…02……02……02…the interconnected equipment for the burden of

…02……02…providing the appearance expected by either end of

…02……02……02…a connection.

…02……02…The Communication User Environment consists of

…02……02……02…entities to establish and maintain communication

…02……02……02…access paths between any two users and to employ

…02……02……02…packets as a unit of data transmission over an

…02……02……02…established virtual path.

…02……02……02…The Data Transmission Environment consists of

…02……02……02…entities to establish virtual circuits between any

…02……02……02…two communication system users assigned and validated

…02……02……02…by the communication user environment.

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 participant 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.

Figure 3.2-3 shows the environments and their
relationship.

Figure 3.2-3

                            3.2.4.1      Network Interface
Environment

…02……02…The Network Interface Environment (NIE) as the

…02……02…outermost layer provides the necessary services to

…02……02…any user accessing an attachment or a participant.

…02……02…The NIE makes the user ap*ear as a valid end user

…02……02…either as defined in the destination or through a

…02……02…mapping onto a virtual network protocol.

…02……02…The NIE provides this service by a conversion or

…02……02…translation of the end user message level protocols

…02……02…and data formats into protocol and data formats

…02……02…dictated by the communication user environment of the

…02……02…network.

…02……02…Virtual Protocol Units (VPUs) provide the

…02……02…presentation service entities which are responsible

…02……02…for mapping the end user protocol to a network

…02……02……02…conversation protocol.  VPUs are software entities

…02……02…which implement the following functions:

…02……02……02…o The sequence number on the data units handled by the

…02……02……02…end user protocol is mapped to the sequence number of

…02……02……02…the data units handled by the network conversation

…02……02……02…protocol.

…02……02…o The segmentation and/or blocking indicators in the

…02……02……02…end user protocol data unit are mapped into

…02……02……02…corresponding control indicators for the data

…02……02……02…units handled by the Transport Service Unit of the

…02……02……02…Communication User Environment.

…02……02…o The throughput control indicators in the end user

…02……02……02…protocol are mapped to the flow control indicators in

…02……02……02…the conversation protocol.

…02……02…o The presentation control indicators in the end

…02……02……02…user protocol are mapped to the device control

…02……02……02…indicators in the conversation protocol.

…02……02…The NIE may provide a second level of translation or

…02……02…conversion of protocols, depending on whether a host

…02……02…facility is interfaced as an attachment or

…02……02…participant. The second level of conversion is needed

…02……02…for participant interfacing.   For these, the second

…02……02……02…level of translation converts protocols and data

…02……02…formats dictated by communication I/O software in the

…02……02…host to the protocols and data formats dictated by

…02……02…the communication user environment.

                            3.2.4.2      CommunicationUserEnvironment

…02……02……02…The Communication User Environment (CUE) provides the

…02……02……02…necessary services to a network user in establishing

…02……02……02…and maintaining a conversation with another user or

…02……02……02…logical unit in a host.

…02……02……02…The Communication Access Path (CAP) is a fundamental

…02……02……02…entity of the network.  The CAP is the b{sis for

…02……02……02…providing a given number and type of communication

…02……02……02…channel to the network user. It provides the means

…02……02……02…for implementing network resource control. The CAP

…02……02……02…has the following characteristics:

…02……02……02…-  a finite fluctuating bandwidth

…02……02……02…-  a finite predictable error rate

…02……02……02…-  a unique identity recognisable throughout the

…02……02……02…network

…02……02……02…Two end users exchange data through a "con-

…02……02……02…versation".  A conversation is the highest level of

…02……02……02…protocol within the network. The conversation is by

…02……02……02…definition at a level below the end-user-to-end-

…02……02……02…user protocol.

…02……02……02…Each end user must have a CAP assigned before a

…02……02……02…conversation can be opened. The conversation

…02……02……02…protocol ensures proper flow of user messages

…02……02……02…between the associated two CAPs and provides error

…02……02……02…recovery facilities to avoid loss of messages.

…02……02……02…Referring to Fig. 3.2-4, "Network Protocols",

…02……02……02…end-user-to-end-user protocol is determined by the

…02……02……02…complexion of the host facilities.  There may be as

…02……02……02…many end user protocols as there are distinguishable

…02……02……02…types of hosts and distinctly supported end user

…02……02……02…types amongst the hosts.  In the proposed ACDN there

…02……02……02…is only one conversation protocol.

Figure 3.2-4

                            The conversation is built
upon the Virtual Protocol
Unit (VPU) entities of the NIE and Transport Station
User (TSU) entities of the CUE.  The TSU is a soft-
ware entity.  The data areas and control functions of
a TSU implement the following functions:

o  Accept and validate a user request for a

…02…communication service provided by the network.

o  Assign a communication access path under a unique

…02…identity.

o  Interrogate the end users and determine the basic

…02…conversation parameters.

o  Based on the conversation parameters obtained from

…02…the user allocate the resources to the CAP

…02…required to support a chosen traffic type and

…02…chosen conversation protocol characteristics.

o  Inform the Network Services Environment of the

…02…resources assigned to the CAP and obtain the

…02…needed physical routing alternatives.

o  Reserve and bind the CAP resources.

o  Based on the conversation parameters initialise

…02…the conversion parameters *n the VPU of the NIE

…02…and in the Data Transmission Environment for

…02…sustaining a conversation.

The CAP services *rovide the operational facilities
necessary to sustain open conversations by:

o  Managing resources allocated to the active

…02…communication access paths.

o  Monitoring the operation of the conversation

…02…protocols.

*** LINE REJECTED ***

…02…the following levels.

…02…-  messages generated by the network services

…02…environment to inform node or other network

…02…catastrophic failure conditions are given the

…02…highest priority,

…02…-  messages generated by the NSE to change routing

…02…primitives at the nodes are given priority at

…02…the same level as protocol responses indicating

…02…the loss of integrity in the end-user-to-end-

…02…user protocol,

…02…-  transport user traffic,

…02…-  interactive user traffic,

…02…-  batch user traffic,

…02…-  messages exchanged by the NSEs distributed in

…02…the various nodes and the Network Control

…02…Center for collecting statistical data, are

…02…assigned the lowest priority.

                            3.2.4.3      Data Transmission
Environment

…02……02……02…The Data Transmission Environment (DTrE) forms the

…02……02……02…outermost layer of the transport network.  The DTrE

*** LINE REJECTED ***

…02……02……02…networR transport service users (TSUs):

…02……02……02…o  DTrE provides a number of logical channels for

…02……02……02…transmitting data.

…02……02……02…o  Each logical channel supports traffic in both

…02……02……02…directions, logically independent of traffic on

…02……02……02…other channels.

…02……02……02…o  DTrE assigns "ports" to communication system users

…02……02……02…to access the transport network at a packet level.

…02……02……02…o  DTrE assigns based on the traffic characteristics

…02……02……02…demanded by the TSU:

…02……02……02…-  a packet level interface with a datagram/fast

…02……02……02……02…select type of protocol,

…02……02……02…-  a packet level interface with a switched virtual

…02……02……02……02…circuit (virtual call) protocol,

…02……02……02…-  a pacRet level interface with a permanent

…02……02……02……02…virtual circuit protocol.

…02……02……02…o  For certain pre-assigned attachments or

…02……02……02…participants, the DTrE associates the relevant TSU

…02……02……02…with a permanent receiver from TSU.

…02……02……02…o  The DTrE implements for each logical channel a

…02……02……02…flow contro* based on the flow control parameter

…02……02……02…received from the associated TSU.

…02……02……02…o  The DTrE maintains a bi-directional interface for

…02……02……02…each trunk interconnecting network nodes with the

…02……02……02…next layer Data Link Environment.

…02……02……02…The DTrE provides an interface to CUE to extract

…02……02……02…optional facilities parameter from the packet.

…02……02……02…Use of optional facilities are in accordance with

…02……02……02…X.75  level 3.

                            3.2.4.4      Data Link Environment

…02……02……02…The Data Link Environment is the second inner layer

…02……02……02…of  the transport network.  The DLE provides the

…02……02……02…necessary functions to support a Data Link Control

…02……02……02…procedure between two DTrE utilising conventional

…02……02……02…transmission media.

…02……02……02…The DLE is a homogeneous entity and support the LAPB

…02……02……02…procedure defined as X.25 level 2.

…02……02……02…The DLE at any one node, is interfaced on one side to

…02……02……02…the DTrE, and on the ot*er side to the DLE of the

…02……02……02…remote node.  The entity utilised to implement the

…02……02……02…conversion is a frame.

                            3.2.4.5      Network Services
Environment

…02……02……02…The Network Services Environment (NSE) provides the

…02……02……02…facilities required to support

…02……02……02…-  connectivity of network users

…02……02……02…-  participatory inter*aces

…02……02……02…-  maintaining the integrity of the networR

…02……02……02…configuration

…02……02……02…-  collecting short term and long term statistics on

…02……02……02…network services utilisation

…02……02……02…-  a set of commands to be used by ACDN operators to

…02……02……02…monitor the static and dynamic status of the

…02……02……02…networR.

…02……02……02…The NSE is implemented in a distributed manner.  The

…02……02……02…scope of the functions to support the above

…02……02……02…facilities is *resented below.

…02……02……02…The NSE validates a user request to get conected to

…02……02……02…the network and use its services.  Validating the

…02……02……02…request implies prior knowledge of the user by the

…02……02……02…NSE.  An important part of the network LOGON is

…02……02……02…authentication, i.e. the validation of the

…02……02……02…identification of the user.  A result of a succesful

…02……02……02…completion of a LOGON is the creation of the

…02……02……02…capabilities against which authorization is to be

…02……02……02…checked during subsequent network transactions.

…02……02……02…It is emphasised that this LOGON to the network is

…02……02……02…independent of and does not replace the LOGON

…02……02……02…procedure that may be required by an application

…02……02……02…program in a participatory host.

…02……02……02…Facilities needed to access and interrogate the status

…02……02……02…and availability of applications are provided by the

…02……02……02…NSE.  These are realised by providing a set of

…02……02……02…emulated application programs.  These application

*** LINE REJECTED ***

…02……02……02…interrogations provide the data needed by the NSE

…02……02……02…to validate connectivity requests by a network user.

…02……02……02…The NSE maintains the integrity of the network

…02……02……02…topology by

…02……02……02…-   recognising link failure and implementing back-up

…02……02……02…routing

                            -   recognising node failures
and imple{enting

…02…recovery procedures

-   recognising overload on links and implementing

…02…back up routing

-   recognising catastrophic failures at the NIE level

…02…and removing the attachements or participants from

…02…the network.

The NSE collects end user st*tistics primarily at the
level of an end-user-to-end-user connection.  The NSE
initialises the statistics gathering at the NIE and
CUE level when an end user protocol is initialised.
The statistics are forwarded to the NSE once the end
user exchange is terminated.

                            3.2.4.6      Network Architecture
Realisat****

…02……02…A number of system elements might be implemented by

…02……02…combining appropriate com*on*nt *arts of the networR

…02……02…ed hitecture.  The generic networ* elements presented

…02……02…in this section highlights the realisations feasible

…02……02…within the architecture.  It is an attempt to provide

…02……02…the Air Canada Technical Management function with the

…02……02…perspectives of the proposworACDN.

…02……02…Figure 3.2-5 "Network Architecture Realisations"

…02……02…illustrates how the internal environments may be

…02……02…combined to form the following elements:

…02……02…NCC -  Nodal Control Center, which implements central

*** LINE REJECTED ***

…02……02…NSH -  Network Service Host, dedicated network

…02……02……02……02…element, which implement network services; e.g.

…02……02……02……02…a NMH provides network administrative and

…02……02……02……02…planning services while an EMH provides a

…02……02……02……02…protected mess{ge service; These elements

…02……02……02……02…are participants in the net Nok.

…02……02…Node - A generalized term used for an integrated MIP,

…02……02……02……02…TIP and switching node,

…02……02…Switching Node - the switching nodes are configured

…02……02……02……02……02……02…to realise the CUE, DTrE, and DLE.

…02……02……02……02……02……02…transport services.

…02……02…HIP  - thes ist Interface Processor implements a host

…02……02……02……02…front-end capability combined with integration

…02……02……02……02…into the network by means of the switching

…02……02……02……02…node element of the HIP.  The physical and

…02……02……02……02…logical interface towards the host is a

…02……02……02……02…channel which operatede.n accordance with the

…02……02……02……02…applicable mainfr{me vendor standards.

…02……02…TIP  - the Terminal Interface Processor implements

…02……02……02……02…the interfaces to the various terminal devices

…02……02……02……02…to be attached to the network.  The TIP is

…02……02……02……02…integrated with the switching novic

…02……02…MEDE - the Message Entry and Distribution Environment

…02……02……02……02…are configured to realise the (remote)

…02……02……02……02…attachment functions of the NIE.  The

…02……02……02……02…physic{l hardware configuration of the MEDE

…02……02……02……02…reflects the interfacing requirements of the

…02……02……02……02…various deeraes to be attached.

Figure 3.2-5

                            3.2.5        Deliverables

…02……02…This section presents the ACDN deliverables in the

…02……02…context of the general network architecture presented

…02……02…in the previous section.  The hardware elements and

…02……02…software pack{ges of the ACDN are defined and mapped

…02……02…onto the internal environments of the network

…02……02…architecture.

…02……02…The proposed Air Canada Data Network might be seen as

…02……02…basically three environments:

…02……02…-  Network Interface Environment,

…02……02…-  Communications Environment, and

…02……02…-  Network Services Environment.

…02……02…The Communication Environment consists of the Data

…02……02…Transmission and the Data Link Environment of the

…02……02…general architecture.  The Communications Environment

…02……02…establishes and maintains basically error free

…02……02…communication paths between any two users.

…02……02…The Network Service Environment includes applications

…02……02…for network management {nd administration as well as

…02……02…a protected message service.  These added value

…02……02…services are offered to users of the ACDN.

…02……02…The relation between the internal and the external

…02……02…environments is depicted in Figure 3.2-6 "Proposed

…02……02…Network Architecture".  This figure and Figure 3.2-7

…02……02…provide the mapping of the hardware and software

…02……02…which constitute the basic elements of the ACDN.

                            *******************

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 Winnepeg.  The NSPs are
controlled locally by a redundant Nodal Control
Processor (NCP).  The term node as used in this
proposal is used for the system made up by the NCP
and NSPs of a location.

The nodes provide the termination points to equipment
of all external environments whether in form of host
data channels or communication lines to terminals and
to other networks, whether internal or external.
This allows Air 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

*** LINE REJECTED ***

Communications Environment.

The Network Service Environment is implemented on a
number of processors each dedicated a specific set of
services.

A Network Control Center (NCC) implements the network
control facilities to designated network operators,
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 Montreal
node.  This results in increased surviviability of
the proposed network.

A Network Management Host (NMH), which provides
network administrative, planning and development
facilities, is implemented by the same type of

*** LINE REJECTED ***

An Electronic Mail Host (ENH) 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,
while long term storage is provided in form of magnetic

ta*e.  The EMH as the NMH is co-located with the
Toronto node.

                            Network Interface Environment

The Network Interface Environment is the outermost
layer of the ACDN.  It provides a direct physical
and logical interface with the external environments
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 network, passive
in form of e.g. att{chments like the present Air Canada
terminal equipment.

The software which implements these capabilities are:
-  Host Access Software                  (HAS)
-  External Network Access Software   (ENAS)
-  Terminal Software                     (TAS)
-  Internal Network Access Software   (INAS)

The NAS implements access methods which operate at
mainframe data channel speed while the TAS implements
access methods which operate with communication
lines.  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 software is to
provide the services necessary to allow a user of the
ACDN e.g. 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, the user|s data to a
format more suited to the host.

The NAS and TAS participates in establishing and
maidivided in entities.  There will be one such
entity for each type of host or terminal (inclusive
external and internal networks).  They share the
nodal switch processing equipment.

In summary, the application of a data channel

*** LINE REJECTED ***

host processor.  The 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-over cost-effective computing
environment.

                            ********************************

The Communications Environment provides in a sense
the backbone services o* the ACDN.   It controls the
interconnections between the users and provides the
data transport{tion facilities.  Softwarewise, it is
implemented by mutually interconnected Nodal Switch
Software (NSS) executed in Nodal Switch Processors.
The NSS implements a trans*ort network by providing
transport, network, data link, and physical link
services 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 layers.  CCITT X.75
recommandation forms the basic upon which the NSS is
implemented.

The following essential service types are provided by
the NSS to the Network Interface Environment:

-  datagram/fast select type of service
-  virtual call

-  permanent virtual circuit

-  priority

-  end-to-end acknowledge

-  end-to-end 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 header and employment
of an efficient routing strategy.

Unrecoverable errors are handed over to network
control/system control software.

                            Network Services Environm*nt

The Network Services Environment provides first of
all global control facilities, secondary added
services in form of protected message service,
administrative billing and planning services and
development capabilities.

The network control facilities are provided by the
Network Control Software (NCS) of the NCC supported
by the System Control Software (SCS)  located in the
nodes.  The protected message 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 tools, using the processor equipment of
the NMM.

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
permanently 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
configur{tion control information and statistics.
The NCS plays an 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 provided by the network.

Basically EMS maintains the PMS traffic database of

*** LINE REJECTED ***

maintains a long term storage of PMS traffic on
magnetic tapes.

                            3.3           Pro*****************************

…02……02…A common computer architecture is used to implement

*** LINE REJECTED ***

…02……02…Host and an Electronic Mail Host.  The equipment

…02……02…used is based on the CR80 computer series, designed

…02……02…and manufactured by Christian Rovsing.  The CR80

…02……02…is configurable and satisfies the broad range of

…02……02…applications of the ACDN, present as future,

…02……02…providing a fault toler{nt data-, packet-, and

…02……02…message switching network.

…02……02…An overview of the specific system configurations is

…02……02…shown in Figure 3.3-1.  It reflects the baseline

…02……02…network for 1985 and illustrates the presence of the

…02……02…generic network elements positioned in accordance

…02……02…with the concept network provided by Air Canada.

…02……02…The proposed ACDN nodes, NMH and EMH have all been

…02……02…configured as selfcontained computer systems.

…02……02…The NCC facility has in the baseline network been

…02……02…integrated hardwarewise with the Toronto node and a

…02……02…back-up NCC facility is proposed as part of the

…02……02…Montreal node.  Hosts and access lines to terminals

…02……02…are terminated at the nodes as described in the above

…02……02…mentioned document.

…02……02…Deviation from the concept network are found in the

…02……02…areas of the Air Canada Gateway to the existing ACNC

…02……02…and in the handling of the external networks, e.g.

…02……02…SITA, ARINC and CNT.

Figure 3.3-1

                            Both of these have for various
reasons been
integrated into the nodes.

The Gateway has been integrated into the node due to

*** LINE REJECTED ***

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 present
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 an communications environment and do

…02…as such logically belong to the terminal access type

…02…of software.

-  Apart from the fact that they today carries type

…02…"B" traffic only, there seems in our opinion not

…02…to be a reason for a termination at the EMH.

-  Last, but not  least, integration of this

…02…capability into the node allows termination of

…02…lines from these external networks at {ny of the

…02…proposed nodes.

All critical elements of the ACDN, i.e. the NCC,
nodes and ENH are configured to provide the high
level of fault-tolerance characteristic to 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 configurated as a
complete CR80 system with all processors integrated
by a common high speed local area bus structure.
Regardless of the configuration, however, the basic
processor, memory modules, and *evice controllers
are the s,se.  T*e detail,* configurations are
described in Chapter 5 of this document.

                            The CR80 hardware configuration
compris*s 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 interconnected by a group of
16Mbps supr{busses.  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 switch{ble and/or monitored
assemblies, such as CPU|s, busses, power sup*lies,
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, which 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 th,t transition phsse
1984-1985 may in 1986 be sublimated into the role of
terminating new terminal equipment.

The partitioning of the computer system into a

*** LINE REJECTED ***

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 remaining system is fully operational.

                            3.4           Pro****************************

…02……02……02…This section presents an overview of the proposed

…02……02……02…package is found in chapter 6.           *tion for each

…02……02……02…package is found in chapter 6.

…02……02……02…The software pro*osed have b*en collected in a number

…02……02……02…of packages.  The packages have been based upon func-

…02……02……02…tionality and a requirement of a |minimal| interface.

…02……02……02…The packages consist of components based on the same

…02……02……02…criteria.

…02……02……02…Furthermore, the software pack{ges plays an important

…02……02……02…role in providing visibility to the Air Canada|s

…02……02……02…Technical Management during the implementation phase

…02……02……02…of the ACDN.

…02……02……02…Before embarking on a more detailed description of

…02……02……02…the individual packages being proposed, is a mapping

…02……02……02…onto the seven-layer Open Systems Interconnection

…02……02……02…model presented.  Figures 3.5-1 and 3.5-2 depicts

…02……02……02…this mapping.

…02……02……02…The application layer of the OSI model is represented

…02……02……02…by the packages implementing value added services to

…02……02……02…the network, i.e.

…02……02……02…-  Network Control Software

…02……02……02…-  Network Management Software

…02……02……02…-  Electronic Mail Software

…02……02……02…These services uses the lower layers implemented by

…02……02……02…the remaining packages to make the services offered

…02……02……02…available to all users of the network.

Figure 3.4-1

                            The presentation and session
layer of the OSI model
is encompassed in the Networ* Interface Environment
as implemented by the following software pack{ges:

-  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 to 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 provides the operating system upon
which the ACDN will be implemented.  DA*OS 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 no process is capable of blocking all
available resources managed by DAMOS.  Data integrity
and privacy is protected by kernelised mechanisms.

The Basic Transport Service (BTS) em*loyed on the
LME-net provides the vechicle for implementing
interactive and batch oriented connections.  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 memory once.  The Basic Ser-
vices provides a queue type 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 the NMH and NCC.

Figure 3.4-3

                            3.4.1        Access Software
Packa***

…02……02…To generalize the functionality of the interfaces,

…02……02…the network provides service to interactive terminals

*** LINE REJECTED ***

…02……02…residing in the network.

…02……02…In general the choice of virtual protocols depends on

…02……02…tioned it is the intention of Christian Rovsing to

…02……02…implement other necessary virtual protocols on

…02……02…request.  For instance a standardized gr{phics proto-

…02……02…col or a protocol covering the very high speed

…02……02…classes satellite-communic{tion.

…02……02…The backbone network proposed provides the following

…02……02…levels of service:

…02……02…-  Packet switching (CCITT|s X.75)

…02……02…-  Virtual File transfer,

*** LINE REJECTED ***

…02……02…-  Virtual Terminal Interaction

…02……02……02…(ECMA|s Virtual Terminal Protocol)

…02……02…A virtual protocol is one, which is not used by any

…02……02…actual equipment attached to the network, at least

…02……02…not as yet.  Actual equipment protocols attached to

…02……02…the (ACDN), network must be mapped onto the virtual

…02……02…protocol supported by the network.

…02……02…Future equipment should be designed to work directly

…02……02…with the virtual protocols in t*e network.  By pro-

…02……02…viding a baseline for future communication via the

…02……02…network, the virtual protocols are the vehicle for

…02……02…commonality in the ACDN.

…02……02…In the selection of the virtual protocols for the

…02……02…network, one must investigate carefully the trends of

*** LINE REJECTED ***

…02……02…monly adopted in Europe.

…02……02…Should this not be so for the Canadian environment,

…02……02…other virtual protocols may be selected for the AC*N.

                            The packet switching service
is carri*d out by an
Nodal Switch Subsystem.  This constitut*s the lower
level of data transfer service offered by the ACDN.

The File Transfer 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 FTP-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. *rinter files,
whereas at { later st{ge a full implementation
including |ob-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 defines a low level virtual terminal standard
by the three standards X.3, X.2B {nd 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 sufficient 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|s like UTS 400 and
IBM 3270BSC, the line of 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 3.4-1 they
interface 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 available
resources and mechanisms.

                            The Internal Network Access
Software PacRages
implements the network function for interconnecting
the old ACNC network and the new network.   Operating
a number of 9.6 kbps the Gateway acts against the
ACNC as multiple I*C|s.  Against the new backbone
network the Gateway maps interactive-, printer-, and
host-traffic into the virtual protocols for
interactive terminals {nd file transfer,
respectively.

The External Network Access Software Pack{ge plays a
similar role in mapping external connections onto the
internal.  The following networks are interfaced:

-  ARINC

-  SITA

-  CNT

                            3.4.2        Nodal Switchin**********************

…02……02……02…The Nodal Switching software implements the bridging

…02……02……02…between the software of the other packages, whether

…02……02……02…between entities of the TAS (supporting a given

…02……02……02…terminal type) and entities of the HAS (supporting a

…02……02……02…given host type) or to a network provided service as

…02……02……02…implemented by e.g. ENS in form of protected message

…02……02……02…service.

…02……02……02…The NSS is also the software which directly

…02……02……02…interconnects the nodes of the ACDN.  The

…02……02……02…transmission media proposed are 56 Kbps internodal

…02……02……02…trunks.

…02……02……02…The services provided by the NSS are:

…02……02……02…-  virtual ca*l service,

…02……02……02…-  permanent virtual circuit services,

…02……02……02…-  datagram/fast select type of service.

…02……02……02…The CCITT X.75 Recommandation is employed on all

…02……02……02…internodal trunks.

…02……02……02…Transport service users are assigned |ports| to

*** LINE REJECTED ***

…02……02……02…control purposes while virtual calls are used for low

…02……02……02…frequency traffic, i.e. interactive {nd batch type of

…02……02……02…traffic.  Transaction type of traffic makes use of

…02……02……02…the datagram/fast select type of service.  Several

…02……02……02…grades of service are offered to transport service

…02……02……02…users:

…02……02……02…-  priority

…02……02……02…-  end-to-end acknowledge or not.

*** LINE REJECTED ***

…02……02……02…the ability to have a given message being

…02……02……02…simultaneously transmitted on several internodal

…02……02……02…trunks within the same group.

…02……02……02…The switching of data implemented by the NSS depends

…02……02……02…on the type of connection.  Transactions are |moved

…02……02……02…in memtions are served by the Basic Transport Service.

…02……02……02…This minimizes the delay through the NSP and thus

…02……02……02…results in a reduction of switching memory buffers.

…02……02……02…The data link service is implemented in firmware.

…02……02……02…The term firmware refers to software reciding in the

…02……02……02…CRB0 line terminating unit, the LTU, even though this

…02……02……02…is actually software which is downlineloaded at

…02……02……02…initialization by the NSP.  The firmware includes a

…02……02……02…buffer manager and a line handler.

Figure 3.4-4

                            3.4.3        Network Control
Softw{re Packa**

…02……02…The Network Control Software (NCS) *lays a key role

…02……02…in maintaining the integrity of the ACDN network.

…02……02…The capability to support a geographically remote

…02……02…back-up NCC provides added survivability to the

…02……02…network.  The NCS consists of software components

…02……02…resident in the Nodal Control Center co-operating

…02……02…with the distributed System Control Software

…02……02…components of the nodes and other computer systems of

…02……02…the network.

…02……02…Probably the most important t{sk of the NCC is to

…02……02…provide the operational people with an environment

…02……02…and with facilities which can assist these people in

…02……02…conducting a safe network operation.

…02……02…The facilities made available to these *eople consist

…02……02…of colour monitors and operational procedures aimed

…02……02…at providing static and dynamic information of the

…02……02…system.  The procedures made available to the

…02……02…operators are based on menu selection and provides

…02……02…the means for obtaining a fast and efficient usage of

…02……02…the network control and monitoring facilities

…02……02……02…implemented.

…02……02…Various graphical presentations are included from a

…02……02……02…complete network picture covering hosts, all major

…02……02…network elements as well as feasible terminal network

…02……02…presentations to diagrams presenting resource

…02……02…utilizations.

…02……02…An important role played by the NCS is that of

…02……02…Definition, defining external as well as internal

…02……02……02…resources.  The NCS enables the NMH/NCC operator to

…02……02…assign a unique logical name to any network resource.

…02……02…However, the allocation of the network logical

…02……02…identifier is assigned by the NCS and the operator

…02……02……02…can not modify this entity; this is part of the

…02……02…network integrity protection facilities.

…02……02…The NCS is provided with software facilities which

…02……02…enables operators of the NCC and NMH to modify the

…02……02…Global Network Definition (GND) in a dialogue form.

…02……02…Facilities are provided which enables files like e.g.

…02……02…those of the GND to be transferred from the NCC to

…02……02…the NMH and thus enable configuration update and

…02……02…check-out to be performed on a network element

…02……02…operating independent of the live network.

                            The Global Network Definition
(GND) is broken down byGND, a set of definitions for
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 definitions 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
control 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 le{ves unaffected
sessions undisturbed.  Thus, the NCS/SCS leaves 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 whether the
resource goes active at a certain time or if it may
be removed 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
wants to establish a connection with a participant of
the network.  The NCS is responsible for establishing
this connection and in assigning the proper networR
resources    The connection creation is co-ordinated
with the local SCS and check-pointed to disk, both at
the NCC and at the SCS, whether node, NMM or EMM.

                            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 this 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 between the two NCC centers.  The
communication between the two NCCs is through the
transport network of the ACDN.

Included in this p{ckage is also various special test
and trace facilities.  These include provision for
monitoring all traffic in and out of a host, a node
or an internod{l 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 Network Mana****************************

…02……02……02…The Network Management Host functions are included in

…02……02……02…the Network Management Software Package system. It

…02……02……02…includes the functions necessary for administrating

…02……02……02…the network i.e. Subscriber, installation and Billing

…02……02……02…Management, Topology Planning, network simulation,

…02……02……02…statistics and charging information collection.

…02……02……02…Further application subsystems and functions can be

*** LINE REJECTED ***

…02……02……02…supplied.

                            3.4.5        Electronic Mail
Software Packa**

…02……02…The Electronic Mail Software Package implements the

*** LINE REJECTED ***

…02……02…feasible implement{tion.  Several considerations were

…02……02…taken into account:

…02……02…-  store-and-forward mechanisms where PMS messages

…02……02……02…were stored on each nodal disk leads to longer

…02……02……02…response times,

…02……02…-  a solution was considered by which the source node

…02……02……02…took PMS responsibility but this leads to a

…02……02……02…solution where disks became a critical node

…02……02……02…element,

…02……02…-  a requirement for unmanned operation of nodes

…02……02……02…leads towards a central solution as disks are

…02……02……02…avoided for this purpose at the nodes,

…02……02…-  a central EMH leads to one additional hop for PMS

…02……02……02…traffic due to the proposed network topology;

…02……02……02…however, with the proposed internodal trunk speed

…02……02……02…of 56 Kbps only a neglible additional delay is

…02……02……02…added to the all over PMS response time.

…02……02…-  the PMS traffic volumes account for 10% of all

…02……02……02…traffic of the ACDN;   thus, only a minor increase

…02……02……02…results on the load of the transport network by a

…02……02……02…central solution,

…02……02…-  a requirement for long term storage in the order

…02……02……02…of one to two months together wit* the volumes of

…02……02……02…traffic considered leads to magnitic tape as the

…02……02……02…most feasible mass storage for this purpose; this

…02……02……02…implies manned operation or additional load of the

…02……02……02…transport network when long term storage file

…02……02……02…transfer takes place.

…02……02…The PMS data base maintenance is based on the same

…02……02…technique as employed on the store-and-forward

…02……02…message switching developed by Christian Rovsing on

…02……02…the FIKS program.

…02……02…PMS traffic is spooled to a fixed head disk, thus

…02……02…avoiding efficiency derating caused by disk head

…02……02…movements.  A full track is copied at a time to the

…02……02…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 {s received by
EM*.

A network session is est{blished 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 service.  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 request 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
f{ulty PMS messages via an interactive dialogue.
These facilities are based on subsets of the FIKS
implementation which provide similar services.

Statistics collection for this special service is the
Data are collected and retained as for other
sessions.

                            3.5          Performance

…02……02…The results of the performance modelling are presented

…02……02…inlfils the performance requirements of the RFP.

…02……02…Importanct design rationales are presented.

…02……02…The data provided by AIR CANADA has been used as input

…02……02…to derive realistic configurations, both the baseline

…02……02…as projected 86 thru 91 configurations. Furthermore,

…02……02…it is shown how the proposed network provides a growth

…02……02…capacity beyond the 1991 projected requirements.

…02……02…The results presented herein have been based on analy-

…02……02…tic distributions reflecting the fact that neither the

…02……02…LMENET nor the FIKS properly represents an environment

…02……02…like the one presented. Appendix D provides the

…02……02…modelling and analytical results which form the basis

…02……02…for the performance values presented in this section.

…02……02…The following constitute the common assumptions upon

…02……02…which the perform{nce factors of the ACDN have been

…02……02…calculated:

…02……02…-  Poisson arrival pattern

…02……02…-  Service times exponentially distributed

…02……02…-  All servers equally loaded

…02……02…-  All servers have same mean service time

…02……02…-  First-in/First-out dispatching strategy

…02……02…-  No items leave queue

…02……02…A conservative design policy has been adhered to in

…02……02…order to provide AIR CANADA with a sound baseline

…02……02…network implementation with built-in investment

…02……02…protection. No attempts have been made to achieve a

…02……02…minimal hardware solution which could only satisfy AIR

…02……02…CANADA|s current needs and as such present a risk

…02……02…factor.

…02……02…The analysis and trade-offs presented in this section

…02……02…iiil be further refined and detailed as *ould

…02……02…Christian Rovsing be the selected contractor. This

…02……02…critical project activity must be conducted in close

…02……02…co-operation with AIR CANADA personnel.

*** LINE REJECTED ***

…02……02…The nodes of the ACDN provide the termination of con-

…02……02…nected hosts and access lines to terminal

…02……02…concentrators. This section presents the results of

…02……02…the performance analysis for the proposed nodes in

…02……02…terms of volume capacities and transfer times. The

…02……02…rationale for the design which implements these func-

…02……02…tions is presented to provide the background required

…02……02…to evaluate the presented information. The modelling

…02……02…presented covers the RFP requirements as well as the

…02……02…new Corporate Service Information Host in Dorval.

3.5.1.1     End-to-End Res************

…02……02…

…02……02…The end-to-end response times expected for the dif-

…02……02…ferent types of AC*N traffic are summarized below:

…02……02…Response


…02……02…time (sec

3.5.1.2     Processor Utilization and Ca*******

…02……02…The processing time required to switch { transaction

…02……02…is:

…02……02……02……02……02……02……02……02……02……02…15.4 msec.

…02……02…Thus, the switching capacity of a Nodal Switch Pro-

…02……02…cessor (NSP) equipped with four CPUs is:

…02……02……02……02……02……02……02……02……02……02…200 packets/sec.

…02……02…The CPU utilization upon which the proposed ACDN con-

*** LINE REJECTED ***

…02……02…This utilization caters for the additonal handling

…02……02…required by the proposed ACDN virutal protocol

…02……02…handling, emulation, acknowledgements and network

…02……02…control.

…02……02…Furthermore, the choice of this low utilization factor

…02……02…reflects an intent to provide AIR CANADA with a net-

…02……02…work with built-in allowance for later increases in

…02……02…processing requirements.

…02……02…Thus, the capacity of each NSP equipped with four

…02……02…equal CPUs is

…02……02……02……02……02……02…100 incoming transactions/sec.

…02……02…whether received form a terminal or a host.

…02……02…This leads to a total maximum capacity of an ACDN node

…02……02…of:

…02……02……02……02……02……02…1100-1200 incoming transactions/sec.

…02……02…The maximum capacity corres*1 transaction volume.

…02……02…cote, h*wever, that this capacity may be incre{sed by

…02……02…a factor of three to four by a cluster of four

…02……02…co-located nodes.

                            3.5.1.3     Memor***************

…02……02…Tesign transfpacity required in order to support the

…02……02…design transferrate per Nodal Switch Proce*sor is:

…02……02……02……02……02……02……02……02……02……02…120 buffers.

…02……02…The basic assumption behind this is that each buffer

…02……02…holds one trans{ction or th{t three buffers may hold

…02……02…one CSIH interaction. Secondly, it reflects the traf-

…02……02…fic mix represented by:

…02……02……02……02……02……02…-  4 internodal trunk

…02……02……02……02……02……02…- 64 access lines

…02……02…together with a requirement that retransmissions

…02……02…caused by "buffer un{vailable" should be required for

…02……02…less that .1 per cent of all transactions.

…02……02…The above number of buffers excludes any buffers

…02……02…permanently allocated for input handling as caused to

…02……02…reduce input processing time. Furthermore, this

…02……02…capacity does not properly reflect the impacts of the

…02……02…proposed type "B" handling.

…02……02…The proposed NSPs are for all proposed ACDN nodes

…02……02…provide* with buffer capacity in excess of the minimal

…02……02…required.

…02……02…Generally, all memory space which is not permanently

*** LINE REJECTED ***

…02……02……02……02……02……02……02……02……02……02…25 per cent

…02……02…for the typical NSP.

…02……02…The reason for providing this additional memory

…02……02…capacity has been a trade-off of price versus the

…02……02…additional benefits caused by this memory:

…02……02…-  Additional buffer capacity may be used to retain

…02……02……02…type "B" traffic for periods where an access line

…02……02……02…is temporarily out-of-service.

…02……02…-  The additirnal ncdil buffer cl*cations which are

…02……02……02…temporarily out-of-service.

                            subscriber|s awareness of
s*ort variations in AIR
CANADA|s computing resources;  secondly, to protect the
internodal trunk network against excessive load
conditions caused by re-transmissions 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

…02…o tables               10K

…02…o 3000 CRT            48K

…02…SCBs, 2 each       72K

…02…o 1500 other sub|s  24K

*** LINE REJECTED ***

…02…o 180 x 64 bytes      6K

…02…o 540 x 512 bytes    138K            144K3.5.1.4
Internodal Trunk Utilization

…02……02…The utilization on the internodal trunks has been

…02……02…chosen as:

…02……02……02……02……02……02……02……02……02……02…75 per cent.

…02……02…This high utilization factor was decided upon taking

…02……02…the following into consideration:

…02……02…-  minimize number of internodal trunks

…02……02…-  evaluate additional delay caused by high

…02……02……02…utilization versus transmission and queueing delays

…02……02……02…on access lines

…02……02…-  usage of trunk groups advantages due to the better

…02……02……02…service which results from a multiserver

…02……02……02…environment.

…02……02…The effective data utilization of internodal trunks

…02……02…has been estimated as:

…02……02……02……02……02……02……02……02……02……02…81.5 per cent.

…02……02…This utilization factor excludes the ACDN

…02……02…communication header, internal end-to-end

…02……02…acknowledgements, network control traffic and does as

…02……02…such only include the data entering the ADCN.

…02……02…The communication header has for sizing purposes been

…02……02…set to 20 bytes and excludes a trailer of 3 bytes.

…02……02…This accounts for about half of lost bandwidth.

…02……02…Furthermore, it has been assumed that the internal

…02……02…network control traffic is on average 200 bytes.

                            3.5.2       Gatewa*

…02……02…The AIR CANADA "Gateway" has been included as part of

…02……02…the Toronto node by provision of dedicated ACNC LTUs.

…02……02…The total bandwidth proposed between the existing ACNC

…02……02…and the ACDN is:

…02……02……02……02……02……02……02……02……02……02…48 Kbps.

…02……02…The bandwidth has been achieved by 5 LTUs each

…02……02…emulating 4 normal 2400 bps access lines which provide

…02……02…a transfer capacity of:

…02……02……02……02……02……02…50K transactions per peak hour.

…02……02…This traffic corresponds to 10 per cent of the

…02……02…capacity of a fully equip*ed NSP.

…02……02…The integration of the Gateway into the node leads to

…02……02…a migration plan which is capable of being adjusted to

…02……02…substantial variations in workloads.

…02……02…The proposed "Gateway" capability has its response

…02……02…time characteristics in common with other node

…02……02…elements.

…02……02…Thus, the major elements in end-to-end response time

…02……02…for transactions which are exchanged between the old

…02……02…and the new network are:

…02……02…1   Access network delays

…02……02…2  Nodal delays

…02……02…3   Internodal trunk delay

…02……02…4  Gateway trunk delay

…02……02…5   ACNC delay

…02……02…6  Host delays

…02……02…today, whi*e 2, 3, and 4 are additional *elays.

…02……02…The gateway trunk will represent the major

…02……02…contribution in additional delay irrespective of

…02……02…selected trunk speed.

…02……02…Selection of e.g. 24*0 bps would lead to additional

…02……02…response time o* average ?.2 sec. (95%: 2.4 sec.)

…02……02…while 9600 bps leads to average .4 sec. (95%:

…02……02….7 sec.).

                            3.5.3       EMH Modellin*

…02……02…The EMH provides a central store-and-forward

…02……02…switching service of the ACDN. This section presents

…02……02…the results of the performance analysis of the

…02……02…proposed EMH in terms of traffic volume capacities

…02……02…and transfer time. The rationale for the design which

…02……02…implements this function is presented to provide the

…02……02…background required to evaluate the presented

…02……02…information.

…02……02…The EMH implements a design which balances the

…02……02…performance of the utilized storage media:

…02……02…-  high speed main memory

…02……02…-  high speed fixed head disk storage

…02……02…-  medium speed moveable head disk storage

…02……02…-   low speed long term mag tape storage

…02……02…The actual EMH equipment will be tailored to meet

…02……02…projected type "B" traffic volumes. Below are the

…02……02…CPUs and disk paths required to fulfill the projected

…02……02…growth:

The bandwidth of one CPU,
i.e. the maximum number of
PMS transactions one CPU can h{ndle in a given CPU
is:

…02……02…55 PMS trans/sec

To allow for acknowledgement handling, fixed to
moveable head operations, checkpointing, retension 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 Nail Processor (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 Nod{l Switch Processors.

The bandwidth to the fixed head 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 c{pacity of the fixed head storage 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 usage 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 head
portion of the disk storage.

                            The successful storage to
disk results in
acknowledgement of 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 traffic 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 {nd retrieval
from the moveable portion of the disk 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 write operation 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 contribution
from three components:

…02……02…-  delay caused by storage strategy

…02……02…-  write to/retrieval from disk

…02……02…-  switching to node/session handling

The major contributor is the delay caused by the

*** LINE REJECTED ***

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 Reliabilit**********************

…02……02…o The proposed ACDN provides Air Canada with a highly

…02……02……02…resilient network. Surviveability has been

…02……02……02…increased by provision of geographical backed-up

…02……02……02…network control facilities. Protection against

…02……02……02…single point failures is offered in form of a

…02……02……02…fault-tolerant computer architecture. The

…02……02……02…distributed architecture offered provides

…02……02……02…additional advantages in form of graceful

…02……02……02…degradation.

…02……02…It should be noted that the results presented in this

…02……02…section represents an analysis which has been based

…02……02…on RMA requirements far more stringent than those

…02……02…presented in the RFP.

…02……02…a.Individual Subscriber

…02……02……02…***************************************************************

                            4 At most one group of two
access lines per NSP

without service.

5 All NSPs assumed worst case NSPs, i.e. with 36

…02…access lines.

6 Only maximum configured nodes assumed, i.e. with

NSPs).

The results which apply to the network subject to the
above assumptions are as presented below:

MTBFACDN          =  8900  hours

MTTRACDN          =     l5  min

Availability     =  99.9972%

While the individual node (maximum configuration) is

MTBFnode          =  3.l years

MTTRnode          =   l5 min

Availability     =  99.999l%

c Electronic Mail

The RMA analysis results which apply to the Electronic
Mail Host are:

MTBFENH           =   l4 years

MTTREMH           =  48 min

Availability     =  99.9995%

To the above should be noted that it reflects the l99l
EMH configuration and that the disks storages
rates.

                            3.6       Baseline Ca*********************************

3.6.1     Baseline Ca*******

…02……02…The proposed baseline ACDN has been sized to handle the

…02……02…anticipated l985 load. The following summarizes the

…02……02…proposed capacities by location:

…02……02……02……02……02……02……02…Toronto  Montreal  Winnipeg

…02……02……02……02…*******************************************

…02……02…l000 Transactions/hour     766        649         l085

…02……02…Host Connections               2          3
   2

…02……02…Internodal Trunks           4+2       2+4          4+4

…02……02…ICC Access Lines              92        l*8
  7B

…02……02…CSIH Access Lines              *        3l
l0

…02……02…********************************************************************

                            3.6.2       Pro***************

…02……02…The baseline ACDN configurations will be sized to

…02……02…handle the projected capacities.

…02……02…The projected volumes and required network capacity

…02……02…are summarized below:

…02……02…a  *******************.

…02……02…The projected peak hour transaction volume per sec.

…02……02…per node is:

…02……02…Y****************************************

…02……02…******************************************

…02……02…84     l90,8      l6l,8      270,4

…02……02…85     2l2,7      l80,4      30l,4

…02……02…86     254,8      2l6,l      36l,0

…02……02…87     306,2      259,7      433,9

…02……02…88     367,5      3ll,7      520,7

…02……02…89     44l,0      374,0      624,9

…02……02…90     529,2      448,9      749,9

…02……02…9l     635,l      538,6      899,9

…02……02…The above represents the total incoming transaction

…02……02…volume to nodes generated by resources outside the

…02……02…node.

…02……02…b.InternodalTraf***

…02……02…The projected internodal peak hour traffic is:

…02……02……02……02……02……02……02……02……02……02…Internodal Trunks

…02……02……02……02……02…KPBS

…02……02…YEAR    T-M      T-W      M-W      T-M      T-W
M-W

…02……02…*****************************************************************

…02……02……02…84   38.3     ll3.7    l05.9     l.0      3.0      2.8

…02……02……02…85    43.3     l28.6    ll9.7     l.l      3.4      3.2

…02……02……02…86    52.l     l54.6    l43.9     l.4      4.l      3.8

…02……02……02…87    62.4     l85.2    l72.4     l.7      4.9      4.6

…02……02……02…88    74.9     222.4    207.0     2.0      5.9      5.5

…02……02……02…89    89.9     226.9    24*.5     2.4      7.1      6.6

…02……02……02…90   l07.7     319.9    297.7     2.B      8.5      7.9

…02……02……02…9l   l29.3     383.9    357.4     3.4     l*.2      9.5

…02……02…******************************************************************

                            The projected internodal traffic
has been derived
using:

1. the projected transaction volume,

2. the projected length of transactions, type by

…02…type,

3. assuming a communications header of 2* bytes plus

…02…trailer of 3 bytes,

4. assuming l0% network control, acknowledge traffic

…02…with average length corresponding to that of other

…02…traffic,

5. a trunk utili*ation of 75% has been used as

…02…baseline to establish the required number of

…02…internodal trunks.

c  Access Lines

…02……02…ACCESS LINES             IBM LINES

YEAR       T     M     W           T     M     W
*******************************************************

84       8l    96    69           0    27     9

85       92  108    78           0    3l    l0

86      lll   l30    94           0    37    l2

87      l33   l56   ll2           0    45    l4

8*      l59   l87   l35           0    54    l7

B9      l9l  224   l62           0    64    21

90      229  269   l94           0    77    25

9l      275  322  233           0    93    30

*******************************************************

                            3.6.3     Block Dia******

…02……02…This section presents the year by year block diagrams

…02……02…which constitute both the baseline but also the

…02……02…projected growth.

…02……02…Only major network elements have been included:

…02……02…o Network Nanagement Processor     (NMP)

…02……02…o Nodal Control Processors          (NCP)

…02……02…o Nodal Switching Processors        (NSP)

…02……02…o Electronic Mail Processors        (EMP)

…02……02…o Channel Units

Figure 3.6-1

Figure 3.6-2

Figure 3.6-3

…02……02……02….

Figure 3.6-4

                            3.7           Telecommunications

…02……02……02…**********************

…02……02……02…Recently Christian Rovsing|s maintenance subcontractor

…02……02……02…CNCP Telecommunications, responded to an Air Canada

…02……02……02…Request for Information (RFI).  Their response to the

…02……02……02…RFI dated December 15, 198* is included in its

…02……02……02…entirety in this proposal as Appendix E.

…02……02……02…Christian Rovsing feels this document provides Air

…02……02……02…Canada with sufficient details on CNCP|s existing

*** LINE REJECTED ***

…02……02……02…for a total solution to their communication

…02……02……02…requirements.

                            3.8           O*******

…02……02……02…o  The hardware and software structures fully support

…02……02……02…openended growth beyond the projected backbone

…02……02……02…network expansion.

…02……02……02…Potential growth areas are:

…02……02……02…-  Internodal Megabit Trunk Capacity (2Mbit(s)

…02……02……02…-  Voice Switching through the ACDN

…02……02……02…-  Internodal Megabit satellite links

…02……02……02…-  Front End Processor connections to Host Access

…02……02……02……02…Network

…02……02……02…-  Videotex

…02……02……02…-  Telefax

…02……02……02…-  Ecryption

…02……02……02…The (Internodal) trunk capacity in the megabit

…02……02……02…range will be necessary both for the connection of

…02……02……02…the Passenger Management System and for the

…02……02……02…Host-to-Host links in the Host Access Network.

…02……02……02…The CR80 module, the STI, presently interfacing to

…02……02……02…the 16 Mbits/sec SUPRA Bus and the 1.8 Mbit/s TDX

…02……02……02…bus, can be used as the interface to such megabit

…02……02……02…communication lines, together with the appropriate

…02……02……02…adapter.

…02……02……02…This also supports megabit satellite loops, when

…02……02……02…needed, since the STI can have at its disposal up

…02……02……02…to 1 Mega words; and large buffering capacity and

…02……02……02…a selective retransmission function are needed in

…02……02……02…order to provide efficient transmission over the

…02……02……02…long-delaying satellite hops.

…02……02……02…Either based upon present da64 Kbps per channel

…02……02……02…or on the latest compressed-coding transfer chips,

…02……02……02…by which voice channels be as narrow as 240* bps,

…02……02……02…the Air Canada Data Network Equipment is well

…02……02……02…suited to include such types of traffic too.  This

…02……02……02…is indicated as a Common Branch Exchange and as an

…02……02……02…automated office processor with a local network.

…02……02……02…Videotex and Telefax might also be attachable,

…02……02……02…directly or through other public networks.

…02……02……02…These examples were intended to illustrate the

…02……02……02…residence of the CR80 System Ap*roach:

…02……02……02…The system is balanced, i.e. it does not create

…02……02……02…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 will be the needs for further Host
Access Subsystems which are parts of the Most-Access
Network to come.  The CR80 system concept is well
suited for such applications, as shown with the
UNIVAC and IBM host Example offered, and we look
forware to supply parts of the Host Access Network 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.

                            3.8.1       Videotex

…02……02…*********

…02……02…Christian Rovsing is in a position to offer Videotex

…02……02…as an added value service to the proposed ACDN. This

…02……02…product could be implemented as part of the proposed

…02……02…Electronic Mail Service.

…02……02…VIDEOTEX, also known as Viewdata, is a facility for

…02……02…retrieveing information from computer data bases. The

…02……02…information is stored in "pages" in the VIDEOTEX

…02……02…system or may optionally be retrieved from external

…02……02…data bases.

…02……02…VIDEOTEX adds, to a data processing environment, the

…02……02…capability of using low-cost and standardized

…02……02…terinals to interact with different data bases in a

…02……02…user-oriented way.

…02……02…Applications for VIDEOTEX are virtuall inlimited.

…02……02…Here are a few examples:

…02……02…o News Media

…02……02……02…-  news briefings

…02……02……02…-  weather forecasts

…02……02……02…-   restaurant guides

…02……02……02…-  going out

…02……02…o Travel and Tourist Information

…02……02……02…-  time tables, local and global

…02……02……02…-  information on destinations, domestic and

…02……02……02…foreign

…02……02……02…-   local transportation schedules

…02……02……02…-   local entertainment guides

…02……02…o Advertising

…02……02…o Banking

…02……02……02…-   account inquiries

…02……02……02…-  funds transfer

…02……02……02…-  bill payments

…02……02……02…-      |uct/service manuals

…02……02……02…-   financial news service

…02……02……02…-   calculations

                            The VIDEOTEX product has ben
delivered by Christian
Rovsing to the Danish Tele Administrations
implemented on the CR80 computer system.

VIDEOTEX offers the following capabilities:

-  Retrieval of VIDEOTEX images in a CR80 database

-  Generation/modification of VIDEOTEX images

-  Maintenance of user cat{logue

-  Provision for generation of users in user groups

-  Maintenance of password

-  Message service

-  Generation of primary keywords

…02……02……02……02……02……02……02……02……02…*

User terminals acquire acces to the CR VIDEOTEX
system by means of call on the public telephone
network. This facility could be useful as it could
provede a means of establishing a "public" entry
point to ACDN v{lue added services.

The user of this could be a subscriber external to
the aCDN who cluld dial this service. A normal
television modified with low-cost circuit board as a
terminal and provided with a low-cost modem is what
that subscriber needs to use in this facility.

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 succesfully passed.

The VIDEOTEX database is structured hierarchically
around the CR standard product CRAM. CRAM provides
iariable length records and key of a maximal length
of 127 bytes.

                            The VIDEOTEX database supports
the following user
access methods:

-  hierarchical search

-  direct page selection

-   selection by keyword

Modification of VIDEOTEX images in the data base
takes place by means f on-line edit facilities.
Terminals, chich have to use this facility must be
provided with an alphanumeric keyboard.

Similar facilities are available for m{intenance of
the user catalogue. Creation of user groups provide a
possibility for associating users with certain image
groups. Thus, a user may only reacal images, which
are within the user group to which he belongs. This
facility is only available to users with a capability
of modifying the basic data of the system, e.g.
system supervisors.

A password must be assigned at the creation. However,
ther user has facilities available for modifying his
personal password.

The VIDEOTEX product includes a facility similar to
the ACDN Protected Message Service. This includes a
possibility of preformatted images where the user
fills in fields or as free images, where the user has
the whole image at his disposal.

The message, which is stored in a message register,
awaits the reciever|s call-up VIDEOTEX service. The

*** LINE REJECTED ***

messages.

The standard VIDEOTEX product supports from 12 to 60
termination points and 20,000 images if an 80 Mbytes
disk is selected.

DataMuseum.dk

CR80 Wang WCS documentation floppies

⟦15ee765f4⟧ Wang Wps File

Derivation

WangText