@make[article]
@device[x2700]
@style[spacing 1]
@modify[hd2,facecode=k]
@begin[text,topmargin=+1.3inches,leftmargin=+0.45inches,rightmargin=+0.6inches]
blank
@newpage
@section[Introduction]
Edinburgh University is spread across
many parts of Edinburgh with two main "campus" areas and a number of
other scattered departments. This situation has led to a very high
dependence on data networking which has been built up over fifteen years in order
to ensure that students and staff can communicate with either the
main University Services or local department machines.
The current network (see fig 1)
is based on three GEC packet switches supporting
33 hosts and 100 synchronous links [1].
The dispersed nature of the University
has resulted in the development of a separate complex
speech network (see fig 2)[2]. The
University telephone exchanges are
of Strowger type
and the University has evaluated nine submissions for their
replacement. This has allowed
an extensive examination
of the possibilities of using the speech network for carrying some,
or all, of the University data traffic.
The University was
able to take the opportunity of early exposure to one of the latest
technology telephone exchanges in the form of a joint project with
ICL, partly funded by grants from the DTI under a 'Focus' and Preproduction
Order scheme. The project's function
is to connect a DNX2000 PABX to an ICL OSLAN
(Open Systems Local Area Network) and to examine the consequences
of carrying data traffic across the PABX onto the LAN. A project diagram
is shown in Fig 3.
The project is now one quarter way through the evaluation
year giving us the opportunity to examine the data capacity of the DNX2000,
in a way which we had not had with the other manufacturers' products.
@section[Advantages]
There are a number of potential advantages to be gained
by using a PABX for data traffic, they are:-
@subsection[Common Wiring]
The biggest attraction of using a PABX for data traffic is that
the wiring is already in place. The penetration of telephones is
greater than that of terminals. Edinburgh University has 2098
telephone extensions, supporting 2835 instruments,
and 1520 asynchronous connections. The total number
of telephone extensions is static but the number of asynchronous connections
has risen by about 20% per year for the last few years. So an alternative
to laying yet more copper is very attractive. Unfortunately, the
situation is far more complex than that and because the existing telephone
wiring is owned by BT we will actually be rewiring much of the University
when the new exchanges are installed. This new wiring will be capable
of fully supporting both the speech and data requirements for most
users.
@subsection[Direct connection of terminals]
One disadvantage of the existing University network for connection
to certain hosts is that
the network is not transparent to all characters, specifically in the terminal
to host direction, and consequently
the terminal image for users is not the same
as that of a directly connected terminal.
A PABX, by using circuit switching, gives a direct
terminal image even across multiple exchanges.
@subsection[Handling multiple terminal protocols]
A PABX can be used to switch a variety of terminal types
using both different types of protocol and synchronous or asynchronous
signalling in a manner that cannot be done with an X25 packet switch.
This can be of use to users who are running mixtures of differing
protocols such as IBM 3270, ICL CO3 or specialised asynchronous block
mode terminals such as those used by the GEAC Library
machine installed in the University.
@subsection[Connection of a large number of infrequently used terminals]
Terminals whose use matches the same sort of profile as that of the
average telephone call can be effectively handled by a PABX. With
a large number of terminals
being only lightly used a far smaller number of host ports than terminal ports
can be
installed. With a large ratio, say 15:1, the cost approximates to that of
the terminal connection cost alone.
@subsection[Single exchange management]
A conventional PACX (data only exchange) such as a Gandalf or a
Micom also provides the
last three advantages. However, a PABX
would still be needed to handle the telephone traffic.
The advantage of using the PABX for data traffic
is that there is only one system to purchase and maintain.
@subsection[Carrying synchronous X25 traffic]
One method
of operation would be to use the exchange to carry a synchronous X25
call from a PAD (Packet Assembler Disassembler)
to a centrally located X25 switch. This has the advantage
of needing only one 64kb/s circuit at maximum, while carrying up to
16 or 32 simultaneous user calls. Unfortunately we have not yet been
able to test this out as the Data Interface Unit (DIU)
originally supplied
by ICL (the Dataset 1) is not designed to handle synchronous data.
We have only recently received the Dataset 2 which can do so.
@section[Disadvantages]
There are a number of disadvantages in using a PABX:-
@subsection[No system is truly non-blocking]
The new generation
of exchanges has been heralded as non-blocking. In other words
all extensions on the exchange can be active at one time. Although
the central core is non-blocking,
the make-up and use of a real system can not guarantee non-blocking.
This is particularily true
if the system was originally designed for speech only.
The situation is made considerably worse if extensive data traffic is
to be carried between exchanges.
Consider the following: a satellite exchange is connected via a 2Mb/s
trunk to the main exchange. The 2Mb/s trunk can carry at maximum 30
calls at 64kb/s, the remaining two channels being used for signalling.
If more than 30 extensions are installed on the satellite exchange
then the @b[system] is not non-blocking. Although multiple trunks could
be used, in real systems this can cause shortages of ports as well
as being extremely expensive compared to a system carrying speech
traffic alone.
The duration of the average speech call is much shorter than
our experience of the average data call (2-3 mins vs 15-25 mins).
This means that a data call using the exchange uses up far more than
would be expected of the total resource (remember that as it is based
on circuit switching, a connection only capable of running
at 9.6kb/s will still use an
entire 64kb/s circuit).
A group of thirty terminals used simultaneously
will use up an entire 2Mb/s trunk, whereas if packet switching is used,
38 or 48kb/s is quite sufficient. It is therefore clear that if a
@b[system] is being used heavily for data traffic, its configuration
will need to be much greater than one which is carrying speech alone.
A single exchange is capable of carrying significant data traffic. An
estimate for the new Edinburgh University exchanges
(whichever product is chosen) is that each would be
capable of handling some 200 simultaneous data calls in addition to the
speech traffic.
@subsection[The cost is greater than conventional solutions]
Comparing costs of different solutions is very difficult, the eventual
cost being very dependant on the individual configuration.
The following comparison uses the marginal costs only.
Consider Fig 4, which shows the typical manner of connecting a data
terminal (or micro) to a PABX.
The general cost of the
DIU and data port
associated with the terminal side is
between @t[#]800 and @t[#]1000.
A share in a host port and DIU must also be allowed for. In our case a
ratio of approximately one host port to every three terminal ports
would be required.
@need[3 in]
@blankspace[3in]
@need[0.5 in]
The equivalent
cost, excluding wiring, in an X25 network (see Fig 5) is one sixteenth
of a cost of a PAD and its network connection. This comes
to about @t[#]200.
An allowance must also be made for the X25 host connection, this is more
difficult as the connection can be shared with other traffic, such as
electronic mail, file transfer and printer output. A reasonable estimate
would be @t[#]50, giving a total cost of @t[#]250.
@need[2.5in]
@blankspace[2.5in]
The equivalent incremental cost of a PACX, such as a Gandalf, in this
simple configuration is about @t[#]80, with an allowance of @t[#]25 for the
shared host port, a total cost of @t[#]105 is reached.
It must be stressed
that if the total cost of a solution is taken into account, the circuit
switch method requires multiple host input/output connections as well
as the ports within the circuit switch.
The packet switch solution requires only one, or at most a few, ports.
With this taken into consideration a Gandalf type of solution is as
expensive as an X25 one.
@subsection[Limitations of 64K baud]
A much quoted
limitation of a PABX is that any one user is limited to a speed of
64kb/s. In reality this is not as great a limitation as appears at
first sight. Most terminals currently only run at 9.6kb/s and it will
be a long time before a 64kb/s limit becomes an embarassment. A more serious
situation is file transfer between micros or multi-user machines.
The comparison here is with the scale of bandwidth that an Ethernet@+(TM)
or similar fast LAN can provide.
An Ethernet's wide bandwidth is best utilised when it is
supporting the interconnection of a large number of small machines. And our
measurements with both Ethernets and Cambridge Rings, both running
at 10Mb/s, show that hosts interchanging real data using other than
the most light weight protocols generally have difficulty in
achieving a true point-to-point speed of even 64kb/s (See also [3]).
The limitation in transfer capacity is caused by host I/O packet
handling limitations. The cost of handling any fast communication
channel is determined largely by the total number of packets (data
and acknowledgment), rather than the number of bytes, that the host
handles. Very few implementations are capable of negotiating the use
of large packets (1024 bytes or over) and consequently severly limit the
maximum transfer speed.
@subsection[Interference with the Speech Service]
Great care must be taken in the overall configuration to ensure that
data traffic, even at its peak, does not degrade the performance of the
speech service. In particular, there must always be spare channels
throughout the system to ensure that emergency calls and the like can
be made.
@subsection[Lack of Network Management]
None of the products investigated by the University support @b[internal]
call monitoring. The consequence of this lack is that it is not possible to
monitor the extent of the data traffic for either future planning purposes
or to safeguard the speech service.
@subsection[Lack of access to a Name Directory]
It is not possible for a user on a terminal to access the PABX directory on
any of the exchanges investigated by the University. This restriction makes
the user interface much more unfriendly than it need be
as users need to remember the name of a particular service to access it.
@section[The Future]
From the above it is quite clear that it is not yet economic
for Edinburgh University to use a new PABX for extensive data traffic.
The question
which now arises is how to make the use of a PABX
more attractive in a general data environment.
Considering Fig 4
again, each of the elements needs to be examined.
@subsection[The Data Port]
There are three ways using the DNX2000 by which a user can establish
a call from one data port to another. The first is to use the telephone
handset to dial the number of the other port; this procedure can be
made very simple by using the 'speed call' feature although there
is an interesting problem with the DNX2000
in that this can't be done when there is
an active speech call
unless a 'feature phone' is used.
The second method, which is only applicable
to RS232 type devices, is to enter into a conversation with software
within the exchange. This software announces itself and then prompts
the user for a command. The user may then call a port by name.
The third method is by 'hotlining', by which a connection is made by
default for the user.
Thus data ports are more complex than speech ports
and are used in smaller numbers; one can
assume that the data port
cost will always be greater than the speech equivalent.
The general cost will fall over time but the overall cost is going
to be heavily dependent on what the PABX manufacturers can charge
for their products in the voice market.
@subsection[Data Interface Unit (DIU)]
The current cost of the DIU is extremely high; for some time now
the manufacturers have been promising a chip to do the job. When these
chips are in volume production one can expect the cost to be only a
few pounds and the expectation is that they will be a standard part of
at least the 'feature-phone' type of equipment [4].
@subsection[Alternatives to the DIU]
@paragraph[Combined micro/telephone]
Products such as
the ICL 'One Per Desk' are interesting examples of the
combination of a micro computer and a telephone, particularily in an
office environment where the
number of devices and their size is of importance.
The cost is still quite expensive
and they have the disadvantage
that the user is locked-in to the particular micro used.
@paragraph[Data Network Gateways]
The use of Gateways should be cheaper than multiple DIUs
and are discussed in detail below.
@need[1.5in]
@section[PABX/LAN Gateways]
@subsection[The current position]
When a large number of ports in one location are connected to a
PABX, for example, to serve a host computer, it is necessary to
connect an individual Data Interface Unit to the end of each port (see
Fig 6).
@need[2.5in]
@blankspace[2.5in]
Even when these units can be racked together, as is the case
with the Plessey exchange, the solution is hardly elegant.
These problems can be considerably increased when a number of
different hosts are connected; the maximum number of simultaneous
connections to each host must be estimated and that number of lines
dedicated to each host. Users are very unforgiving when access to
their host is denied because all the ports on the exchange are in use
even though the maximum potential of the particular host has not yet
been reached because only a few 'other' lines are in use. Our
experience has shown that the peak number of users is not usually
reached on all hosts simultaneously, the effects of special courses,
lectures, deadlines and the like cause fairly wide fluctuations in
the demand for any particular machine. In solving this problem, in
common with any PACX use, many more access ports have to be provided
than are actually in simultaneous use.
One partial solution to this problem is to connect some, or all, of
the exchange ports to a PAD. This PAD
is then connected in a conventional manner to a data network which
could be based on a number of technologies, eg, Ethernet, X25 or
Cambridge Ring. The hosts are then also connected to this network, the
typical form of which will allow a varying number of simultaneous
terminal connections. (See Fig 7).
@need[2.5in]
@blankspace[2.5in]
In the Edinburgh case we have connected a number of ports directly
from the PABX to separate hosts, some ports from the PABX to three ICL
OSLUs (Open System Link Units) connected to an OSLAN and a few
connections from the PABX to a Camtec PAD connected to the main X25
network (see Fig 3).
This particular configuration was used to allow us as much
experience as possible with the varying connection methods, but it can
lead to problems for some users because of the differing user images
presented by the different routes.
A further problem arises with the
DNX2000 because the ability to set up 'hunt'
groups is not as flexible for data calls as it is with voice calls.
Consequently it is not possible to have a single hunt group which will
take a direct connection if one is free but also automatically select
a PAD port if all the direct ports are in use.
@subsection[The future]
A more elegant solution for connecting multiple DIUs
is to construct a Gateway either directly on to the end of a 2Mb/s
trunk link or to build a Gateway within the exchange itself. ICL are in
the process of constructing a Gateway to connect a 2Mb/s trunk to their
OSLAN (See fig 8).
@need[2.5in]
@blankspace[2.5in]
We had hoped that we would be able to replace
the OSLUs before the end of the project with such a Gateway but that
is not now going to be possible. The advantage of such a Gateway is
that the DIUs are an integral part of the Gateway and,
more importantly, the Gateway can act in a more integrated way with
the exchange. For example, it would no longer be necessary to allocate
different hunt groups, with pre-set allocations, to handle various
terminal parameters such as different line speeds or differing
protocols - dumb terminals, 3270, CO3 etc. All thirty available
sub-channels would be in a single hunt group, the exchange would pass the
information to tell the Gateway the type of connection to be used and
the Gateway would then set the port up as necessary.
There are other considerations when a terminal is connected to a
host via such a Gateway (or PAD equivalent). The first is what
protocol should be used to carry the terminal data across the OSLAN.
In our case it was reasonably simple; all our terminals are 'dumb
teletypes' and the most obvious choice was to use a variety of XXX
called TS29 [5] that could be run over the ISO Transport Class 4
Service which is used. TS29 allows a free exchange of data bytes but
significantly also gives a standard procedure (X29) for a host to
change various PAD characteristics such as echo control, local edit
control and forwarding rules. This protocol was implemented for us by
ICL who were using a simpler form which did not allow us the control
from the host we considered essential.
One interesting decision that
still has to be taken is where the echoing of the user input is to be
done. One choice is to do it within the host computer. This allows
a terminal image which is identical (or nearly so) to a terminal
which has been directly connected. The problem with this decision is
that both the input and the echo need to be carried across the LAN in
single character quantities. The problem this creates is not one of
LAN capacity but that of delays caused by processing overheads in
both the host and the Gateway. In our experience, users will complain
if echo is held up for more than about one tenth of a second and more
than a few users attempting such single character working leads to an
unacceptable 'stickiness' in terminal presentation. The second way to
handle echo is to do it within the Gateway/PAD itself. A separate
decision can then be made of exactly when the user input is forwarded
across the LAN. This leads to a much better use of the available
performance but means that the terminal image may be different from a
directly connected terminal.
In reality, a mixture of the above
approaches can be used; most of the time user echo can be handled by
the Gateway but the host can take control via X29 at any time to
handle special cases such as screen editing.
@subsection[Integrated Gateways]
Building a completely integrated Gateway is being pursued by at
least one other PABX manufacturer, the outward connection being X25
based.
In a multiple exchange environment it would be extremely useful to be able
to pass the X25 connection through a sub-channel on a trunk to another PABX
to avoid the necessity of all the exchange's being connected directly to the
X25 network.
The considerations discussed above will still apply and at the
end of the day it will come down to a decision on which type of
Gateway will fit better in the user's own data network environment and
the overall cost of the Gateway.
@need(1in)
@section[Conclusions]
As has already been stated, at this stage the use of a PABX for extensive
data traffic is more expensive than the alternative solutions such as
packet switching
or a PACX. When the Data Interface Unit has been integrated into a telephone
handset at a reasonable cost the situation changes and can be divided into
two cases, the single and multiple exchange environments.
@subsection[Single Exchange Environment]
In this situation, the PABX will be comparable to its alternatives, the
incremental costs may still be higher but the advantages of only buying
one system should bring the overall system prices more into line.
@subsection[Multiple Exchange Environments]
The situation here is much more complex.
The PABX
network suffers from severe problems with blocking as was discussed earlier
and a practical solution entails mixing the PABXs with more conventional
data networks such as X25.
The PABX manufacturers will need to
consider much more carefully the needs of the data user and to tackle the
overcapacity associated with pure circuit switching before the PABX becomes
a satisfactory solution.
@section[Acknowledgements]
The author would like to thank F.E.J. Barratt (Telephones Project Manager)
and
W.S. Currie (PABX/LAN Project Officer) for their help and information.
@section[References]
@begin[enumerate]
ERCC - Services and Facilities, 1985, ERCC
Operation Requirement for Replacement of PABX Network, Edinburgh University,
April 1984
Jose Eabielsky, Interfacing to the 10Mbps Ethernet: Observations and Conclusions,
Comms,ACM 1984 pp124-131
Satish Chandra, Integrated Voice & Data PBXs, Tutorial, Compcon '82, IEEE
"Green Book" - Character Terminal Protocols on PSS (Study Group 3, BT PSS User Forum)
@end(enumerate)
@section[Trade Marks]
Ethernet is a trademark of the Xerox Corporation.