©Wilkin, D, Ferranti Ltd., Manchester, UK
This paper was originally presented at the Second International Conference on Computer Communication, Stockholm, August 1974. It published in the proceedings as paper T 2244 pp 199-213.
©Pearson, D J, Ferranti Ltd., Manchester, UK
©Wilkin, D, Ferranti Ltd., Manchester, UK
This article discusses the Ferranti implementation of the British Post Office specification of the Experimental Packet Switched Service (EPSS). Commencing with a brief background to the reasons for the experiment it goes on to highlight the main areas of the specification that significantly influenced the ultimate system design. Discarded solutions are briefly mentioned and some of the main aspects of the chosen solution are discussed in more detail.
For a number of years the British Post Office have been investigating methods of improving and adding to the facilities of the existing telecommunications network to meet the needs of its data customers for both national and international services. The investigation, which covers both transmission and switching facilities, has resulted in proposals being made for Digital Data Services, the initial services of which are expected to become operational in the late 1970s. The services will make use of digital transmission and switching facilities and may be required to provide both circuit and packet switching techniques. Economic studies indicate that digital transmission systems of the type being introduced for general telecommunication usage can provide more economic data services than their analogue counterparts on many routes. It is planned to progressively introduce digital facilities over the next ten years or so and it is reasonable to assume that the majority of inter-city transmission and associated feeder systems installed after 1985 will be digital.
As mentioned above the new Digital Data Services are planned to include a packet switching facility. However, at this time insufficient is known about the viability and technical problems associated with this technique for it to be included with confidence.
Hitherto there has been a great deal of discussion about the advantages and disadvantages of packet switching techniques and a large amount of significant data has arisen from the few private networks already established - so much so that it has been suggested to the BPO that public data services should be based solely on this concept. On several occasions the BPO has stated that it had insufficient evidence of the practicality and viability of the packet mode of working to plan for it to be the main basis of any public service. However, the BPO decided it would be in the interests of both themselves and their customers if an experiment could be conducted to provide data upon which future network planning could be based. To be successful such an experiment would need to be implemented quickly and be of sufficient extent both geographically and in the provision of customer facilities to generate practical data. The resultant proposed public switched service is called the Experimental Packet Switching Service (EPSS).
The experimental network will comprise three nodes, one each at London, Glasgow and Manchester. The nodes will be linked by 48K bit/s digital paths fully duplicated and each node will be equipped with both a number of packet (synchronous) and character (asynchronous) ports of various speeds and Interfaces so providing interface facilities to many users of the existing Post Office Datel services. The EPSS network should be operational by mid 1975 and decisions regarding the future of this mode of data transmission should be available during the following two years to enable the Post Office to finalize its longer term plans.
This article discusses the system design implications of the BPO specification and goes on to describe the chosen solution in terms of system design, hardware and software. In addition problems of implementation and customer participation are briefly touched upon.
The main objective of the EPSS as stated by the BPO(1) is to set up a packet switched data communication experimental network of sufficient capacity, flexibility and geographical extent to satisfy the following requirements:
(1) To enable users to evaluate the overall benefits of packet working within the data processing and data transmission environments.
(2) To enable the BPO to evaluate operational aspects of a packet switched service.
(3) To obtain an indication of likely future demand for a packet switched service.
(4) To define and prove procedures and interfaces with customers and manufacturers of user equipment and hence provide a basis for national and international standardisation.
(5) To assist in determining tariffs for such a service, taking into consideration user and BPO requirements.
Not all would agree that packet switching techniques offer significant advantages over circuit switching techniques but in evaluating the case for a packet switched service the BPO has identified the following key areas in which the packet method of working appears to offer benefits to users of data communication orientated computer systems. These are:
(1) Improved utilisation of communication links. Circuit switching may be regarded as relatively inefficient because the continuously held path is used only spasmodically for the duration of the call.
(2) Simplification of communication control equipment and procedures. Economy can be achieved by standardisation and the replacement of a large number of low capacity lines with a single high capacity line.
(3) Error protection - packets lend themselves to effective error detection and subsequent correction of transmission errors.
(4) Automatic route protection - interference affecting packets in transit may be bypassed by alternative routing.
(5) Such a technique allows interworking between terminals operating at different transmission rates. Data generated at slow rates may be delivered at high rates enabling systems to be optimised.
There are doubtless other benefits to be obtained from the packet switching technique of data transmission and these should be identified as the experiment progresses. However, it is possible that the greatest benefits of all will arise from the information and data produced by the experiment.
Before describing the design of the EPSS, first a summary of the BPO requirements to highlight the main features which influenced system design.
As stated earlier the BPO specified that the EPSS network will consist of three nodes, the minimum size capable of providing alternate routing experience. The nodes or Packet Switching Exchanges (PSEs) are to be situated in London, Manchester and Glasgow and may be fully interlinked by 48K bit/s digital paths capable of operating up to 60K bit/s if required in the future. In addition each exchange is required to be equipped with a number of customer connections, or ports, to allow the connection to the system of two separate categories of customer terminal. The two categories are:
(1) Packet Terminals: terminals capable of constructing, transmitting and receiving standard format packages.
(2) Character Terminals: simpler terminals only capable of operating in a character mode. The local PSE is required to assemble characters into packets and break down packets into characters when connected to terminals of this type
The types and numbers of connection provided at each PSE are shown in table 1. (Note: a zero means facility provided but not used.)
TABLE 1
| NUMBER OF CONNECTIONS | |||
| London | Manchester | Glasgow | |
| CHARACTER LINES | |||
| 50 bd PSTxN (AUTO ANSWER) | 0 | 0 | 0 |
| 50 bd PSTxN (DIAL UP) | 6 | 6 | 6 |
| 50 bd DIRECT | 0 | 0 | 0 |
| 50 bd TARIFF H | 3 | 2 | 2 |
| 110 bd DATEL 110 | 3 | 2 | 2 |
| 300 bd DATEL 200 | 9 | 4 | 4 |
| 110 bd PSTN (DIAL UP) | 36 | 18 | 18 |
| 300 bd PSTN (DIAL UP) | 15 | 8 | 8 |
| 110 bd TARIFF J | 6 | 4 | 4 |
| TOTALS | 78 | 44 | 44 |
| PACKET LINES | |||
| 2.4K bit/s | 12 | 8 | 6 |
| 4.8K bit/s | 6 | 4 | 4 |
| 9. 6K bit/s | 6 | 4 | 2 |
| 48K bit/s | 6 | 2 | 2 |
| 48K bit/s INTER PSE | 6 | 6 | 6 |
| TOTALS | 36 | 24 | 20 |
The monitoring and control of the total network and of each PSE is the task of a Monitor and Control Point (MCP). Each PSE is equipped with an MCP each of which must be able to take over control of the total network on demand.
Each MCP will provide the following main facilities:
(1) PSE start up and shut down.
(2) Monitor congestion, route availability, levels of service and report when preset limits are exceeded.
(3) Monitor specific PSE functions, such as customer call activities, and report.
(4) Initiate and monitor test routines.
The major operations requirement of each PSE is to adequately service the specified traffic loads within the specified limits of grades and quality of service.
To summarise the specified traffic figures, the BPO estimate that each PSE must be capable of handling a peak total of 137 packets (approximately 15000 data bytes) in the busiest second. In the absence of practical packet switching traffic figures for the U. K., the BPO have used information arising from other similar networks together with estimates based upon existing U.K. data traffic. From these it has been possible to assume further traffic figures for:
(1) The distribution of the number of packets in each call in a busy day.
(2) The average number of packets for each call attempt estimated at 51 for each PSE.
(3) The average number of packets for each successful call estimated at 53 for each PSE.
(4) The estimated maximum calling rate for each type of connection and the peak probability of call attempts for each PSE during busiest second. This latter figure is estimated at 407.
While the above estimated traffic information set the upper system design limits care had to be taken to ensure the following grades and quality of service could be met.
(1) The proportion of call attempts which fail during the busiest six minutes because of PSE insufficiency must not exceed 1 in 3000.
(2) The proportion of packet transfers which fail during the busiest six minutes because of PSE insufficiency must not exceed 1 in 300,000.
(3) The frequency of the inability to establish or clear a call due to faulty equipment must not exceed 10 times per year.
(4) Ninety five percent of all calls must be set up within 10 ms, the remainder within 20 ms.
(5) Probability of incorrect call connection due to faulty equipment must not exceed 1 in 3 x 1 0 5
(6) After call set up subsequent packets must not be delayed
within the PSE more than 5 ms (95%) the remainder 10 ms.
(7) The probability of packet loss and mis-delivery must not exceed 1 in 108 and 1 in 109 respectively.
(8) Packet corruption within a PSE must not exceed 1 in
3 x 107 while failure to deliver a packet and complete a call must not exceed 1 in 3 x 105 and 1 in 105 respectively.
The above figures specify an extremely high grade and quality of service and meeting them will be no mean achievement.
Since the EPSS could develop into a public switched service, the network serviceability must be at least as good and perhaps even better than that of other switched networks operated by the BPO. Consequently PSE serviceability is specified as a failure rate which must not be exceeded and these are defined in terms of user rate, length of service break, number of service breaks per unit time and permissible customer connection failure rates.
Typical of the failure rates are those specified for the partial loss of the service to the 48K b/s customer connections. For instance PSE faults which result in more than half the customers or half the trunk and junction circuits being unable to set up or clear down calls must not occur more frequently than the rates given below.
(1) Breaks of 2 ms or less 10 times per hour.
(2) Breaks of 2 ms - 20 ms - once every two hours.
(3) Breaks of 20 ms - 5 s - once a month.
(4) Breaks of 5 s - 10 mins - once in 20 years.
Breaks of small duration do not materially affect system design but longer breaks such as 10 minutes can create problems. Perhaps the most significant specified failure rate which greatly influenced system design is the required Mean Time between Complete Failure of a total PSE which is required to be not less than 100 years. Failures lasting for more than 10 minutes for all users at one user rate is regarded as a complete failure of a PSE. To ensure the above levels of serviceability are maintained in the event of electrical mains failure the PSEs are required to be powered from the main exchange 50 volts DC battery supply. Each PSE is also required to operate in a telephone exchange environment without the use of additional air conditioning and filtering equipment.
In addition to factors arising from the specification, the BPO tendering requirement also produced effects upon the system design. For commercial reasons the BPO set a limit on the amount it was prepared to spend on an experimental service, and consequently tenders were requested for exchanges of differing port size and serviceability to enable the BPO to assess the cost implications of meeting different objectives with a range of exchanges. However, any exchange should be capable of on-site enhancement in terms of serviceability and port size.
This requirement presented the system designer with a further range of system design problems.
Perhaps the largest single factor affecting the design of a PSE is the packet switching protocol and in particular the packet formats.
The BPO have designed the protocol to provide effective and secure transfer of packets through the network, while working within the constraints of the CCITT recommendations for data transmission. Another factor was the desire to keep the ratio between control information and data down to an acceptable level. This has resulted in the use of semi bytes for all EPSS addresses, although a packet always comprises an integral number of contiguous eight bit bytes.
The overall philosophy adopted for the packet protocol is based on the concept of a call. A call is set up by the calling terminal generating a "call originating" packet and the called terminal responding with a "first response" packet. Further packets in the call are called "subsequent" packets, a different packet type number is used to indicate whether the packet source was the calling or called terminal. A fifth packet type, called a "network information" packet, is generated only by the EPSS but may be delivered, as part of a call, to both the calling and called terminals.
The format of packets received or delivered by a PSE has two main sections, these being the header containing control information and the data. When a packet arrives at a PSE from a customer packet terminal it is converted into a form suitable for transmission on the EPSS network by attaching a Main Network Addition (MNA) to the packet immediately after the data. The MNA is removed by the destination PSE before the packet is delivered to the terminal.
The length and content of the packet header and the main network addition are different for the various types of packet. Obviously the length of the data field is variable and may take any value between 0 and 255 bytes.
The lengths of the packet header and the main network addition are determined from the packet type byte, this is first byte of the packet header. The data length is held in the second byte. Figure 1 shows the various fields in a "call originating" packet as it is transmitted in three stages from the calling packet terminal to the called packet terminal.
In addition to the requirements of the call protocol, the packet format is also affected by the line transmission protocols. The main effect is the addition of two bytes at the end of each packet to provide a transmission error checking facility. These bytes are formed, by the sender, from the 16 bit remainder of the division of all the bits in the packet by the checking polynomial
x16 + x12 + x5 + 1
The receiver repeats the division and provided the generated remainder compares with the received remainder the packet is assumed transmission error free. The checking polynomial used is based on CCTTT recommendation V.41. Check bytes are generated each time the packet is transmitted as the content of the control field, and therefore the value of the check bytes, may change within a PSE.
Fields in the header and main network addition are reserved for individual link sequence numbers to ensure arrival and delivery of packets in the correct order.
Initially there were two types of transmission line protocol in use on the EPSS, namely PSE to customer packet terminal and PSE to PSE. There is now a second 'simplified' PSE to customer packet protocol. The difference between the three transmission protocols is the method used to acknowledge received packets. The PSE to PSE links use a full duplex mode of operation where packets are continuously in transit in both directions. The acknowledgement method is to form a sixth type of packet with the data field holding the link sequence numbers of received transmission error free packets. An acknowledgement packet will normally hold one sequence number unless the transmission line is busy. Acknowledgement packets take priority over all other packets.
The original high throughput PSE to customer line transmission protocol allows packets to be transmitted simultaneously in both directions, but second packets cannot be transmitted until the first is acknowledged. High throughput is achieved by generating and transmitting the acknowledgement two byte times after receiving the second check byte. The acknowledgement comprises three identical bytes which are transmitted at the fixed time in the transmitted byte stream, even in the middle of a packet. Two of the main requirements of the PSE and the packet terminal are the ability to maintain synchronism between the receiver and transmitter and the ability to measure the loop delay of a line. During line initialisation both the PSE and the packet terminal measure the loop delay of the line. Therefore the first byte of the acknowledgement will be received 'n' bytes after the transmission of the check bytes -
where n = loop delay + 2 byte times
The simplified customer to PSE line transmission protocol although retaining the full duplex capability reduces the potential line throughput by waiting until a packet is completely transmitted before the acknowledgement is transmitted. The acknowledgement takes the form of the PSE to PSE acknowledgement packet but with a zero data field, as only one packet can be transmitted in one direction at a time the link sequence number is not included in the data field.
When attempting to design a computer interface to these protocols both hardware and programmed solutions were considered. The software solution was found to quickly overload any available processor and consequently a hardware interface system was designed taking advantage of the most up to date logic design techniques. This development is called the Packet Line Card (PLC) which is a microprogrammed, full duplex, synchronous line card capable of operating at transmission speeds of 2.4K b/s to 60K b/s. It is also capable of operating to any of three transmission protocols and this is determined by the physical position of the card within a mounting box. This design concept eases and simplifies problems of design, manufacture and ultimately maintenance. Up to eight PLCs are scanned by a fast multiplexor channel.
Three basic PSE system solutions were considered before a final choice was made. These were:
(1) A duplex computer arrangement with ported stores, cross connected to provide fully operational standby facilities. Line interface equipment would be duplicated and arranged to interface to both processors.
The disadvantages of this arrangement are that the serviceability requirement could not be met and that the system would be largely dependent upon the availability of self reconfiguring hardware and software which could not be developed to the required degree of security within the time scale.
(2) A system comprising a microprocessor for each packet line. Each microprocessor would interface to a multichannel data highway under control of a small duplex central processor.
This concept seemed attractive at the time but is was considered that a suitable microprocessor could not be produced within the timescale.
The PSE design ultimately chosen is based upon the philosophy of sharing the line exchange capacity between a number of similar modular units which are linked together to form a total exchange. Each unit is designed to accept a number of each type of line connection and therefore the failure of one module will not result in the total loss of all one particular service. This module is called the Packet Switching Unit or PSU. In basic form the PSU consists of a processor, store and approximately one third of the required PSE line connection equipment. Serviceability of the basic PSU may be improved by adding a further processor and store to the common line interface equipment. The second processor is arranged to operate in a standby mode and is updated by the main processor. When one processor is on-line the second may be on standby or receiving maintenance. The processors are connected together by a fast store to store link which is also used to interconnect a number of PSUs to form a complete exchange.
Using PSUs of this type it has been found possible to construct exchanges of the required differing line capacity, serviceability and cost.
The expected mean time between total failures of the various types and sizes of PSE are shown in Table 2.
TABLE 2
| ESTIMATED MTBF SUMMARY | ||
| Type of Failure | Single Processor | |
| 2 Unit PSE | 3 Unit PSE | |
| Individual Customers - faults up to 10 mins. | 4 times in 10 years | |
| Over 20% of Customers | 6 times a year | 9 times a year |
| Over 20% of Customers Breaks of less than 1 minute | n/a | n/a |
| Over 50% of Customers | 6 times a year | 1 in 63 years |
| Total failure of PSE | 1 in 100 years | Greater than 100 years |
| Dual Processor | ||
| 2 Unit PSE | 3 Unit PSE | |
| Individual Customers - faults up to 10 mins. | 4 times in 10 years | |
| Over 20% of Customers | 1 in 50 years | 1 in 29 years |
| Over 20% of Customers Breaks of less than 1 minute | 6 times a year | 9 times a year |
| Over 50% of Customers | 1 in 50 years | Greater than 100 years |
| Total failure of PSE | Very large | Greater than 100 years |
Note: Mean time to repair assumed at 5 hours.
After taking into consideration the expected customer usage at the three PSE sites the BPO decided that the London PSE would consist of three high serviceability PSUs and Manchester and Glasgow would each consist of two standard serviceability PSUs as shown in figure 2. These may be upgraded to high serviceability by the simple addition of the standby processor.
The Packet Switching Unit is based upon the Ferranti Argus 700E processor which is a medium sized, 16 bit word machine with the capacity for addressing 64K words of core store and up to six input/output processors or channels. A programmed input/output facility enables the processor to drive input/output devices directly without the need for a channel as an intermediate controller. A total of 128 addresses are available at this interface.
Architecturally the Argus 700E is a microprogrammed machine which uses a data stack for arithmetic working which when used with a subroutine link stacks permits the flexible handling of subroutines.
The basic Packet Switching Unit consists of a single Argus 700E processor complete with 48K of core store, two fast multiplexor channels, and a processor interconnection channel as shown in figure 3. Packet and character lines are interfaced to the machine by a range of line interface cards which form a block of common line interface equipment. This equipment may be addressed by the currently on-line processor. The off-line processor is locked out from the line equipment by the on-line processor which upon failure permits the changeover to take place.
Packet lines of all speeds and protocols are interfaced to the processor by a single type of interface module called a Packet Line Card.
The packet line card is capable of observing three types of protocol, namely, PSE to PSE, PSE to customer (high throughput) and simplified PSE to customer (reduced throughput). The card is designed to operate in a full duplex synchronous mode at 2.4K, 4. 8K, 9. 6K, 48K or 60K bits/second. In construction the card consists of independent transmitter and receiver controller sections which obtain packet information from the transmitter and receiver converters. Controller operating instructions are taken from a Random Access Memory as shown in figure 4. From these two sources of information the controller sets and decrements a series of counters which control and check the Incoming and outgoing packets. In addition the card performs the cyclic redundancy check, finds and maintains byte synchronisation and provides the processor with status information. Modem interfaces to the CCITT V24 & V35 recommendations are also provided on the card.
Of particular interest and complexity is the PSE/customer high throughput protocol in which acknowledgement bytes may be inserted within received packets. To ensure effective detection of the bytes the line card is designed to measure and maintain the loop delay time of the customer connection. Other types of acknowledgement are formed by software. The packet line cards are Interfaced to the processor by a fast multiplexer channel (TFX) which is one of a range of multiplexors available with the Argus 700E. The TFX is a microprogrammed module designed to scan a small number of fast input/output devices and pass data between these devices and processor core store without the intervention of the processor. Up to 16 devices may be driven at a total throughput rate of 100K bytes/second.
In common with all Argus 700 channels the TFX is controlled by device control terms obtained from locations within the main core store and these provide all control information required by the channel for data transfers. A TFX feature of particular interest and used by the PSU is the ability of the TFX to automatically chain block transfers and allocate store space using a paging system.
One TFX is capable of servicing up to 16 devices, an input and output of a full duplex packet line card counting as two devices. Therefore two TFXs are required to service the twelve packet line cards of a PSU.
Where processors require a direct link with other processors within the system such as, in the high availability PSU, the link between PSUs, or to MCPs, a Processor Interconnection Channel is used to provide a store to store connection. The PIC is very similar in design to the TFX and is designed to multiplex up to eight full duplex lines at a maximum total throughput rate of 100K bytes per second.
All character terminals are interfaced to the PSU by one type of program driven asynchronous character handling interface card. The logic unit is capable of operating at transmission speeds of 50 to 4,800 bauds at either 7, 10 or 11 unit character codes.
Where auto dialling is a requirement each character line interface is supplemented by an auto dial logic card which again is program driven to generate and accept dialling pulses from a Post Office supplied autodial connection unit. All character line connection equipment is common and controlled by the current on-line processor.
A BPO requirement not yet mentioned is that each PSE is required to operate In an unmanned environment resulting in very few peripheral devices being required. Each PSU is equipped with facilities for the attachment of a cassette tape reader and printer for program loading and fault investigation purposes.
Each PSE is equipped with two rotating drum stores each of 1 Mbyte capacity. The drums are used to store customer billing data and system operation records before transmission to a billing and statistics terminal on the network. The drums operate in a master and standby mode, data being written to both drums.
Under normal operating conditions the control processor has exclusive access to the shared line interface equipment, the signal allowing access automatically locking out the standby processor. To maintain this access the control processor must address the Isolate/Connect logic with a number of addresses at defined intervals. Failure to do this will result in the time out of a preset timer which causes the standby to become the control processor if this machine is available.
Software for the EPSS is written using standards developed for the Ferranti Argus 700 range of computers. Software is identical for each PSU and is essentially modular in design.
Programs are written in the CORAL 66 programming language. CORAL is a high level language using block structuring. Data in CORAL is accessible as bits, bytes, words or fields giving greater efficiency of core utilisation than is available with most other high level languages. Machine dependent and time critical code is written in usercode - like instructions using the Argus 700 Instruction set. This code is included within a CORAL program using the 'In-line Code' facility of the CORAL compiler, and may reference other CORAL programs and CORAL data structures.
The heart of the EPSS software is the Organiser. This is the standard Argus 700 Organiser for core based systems. The Organiser has two main areas of responsibility, namely Executive functions and Device Control Programs.
The Executive provides overall program control and the method of program interaction, including:
(1) Provision of standard well-defined Interfaces between various levels of program.
(2) Access from higher level Interrupt programs to Executive functions.
(3) Access from Task programs to Executive functions by means of an Organiser Call.
(4) System clock routines, based on a 5 millisecond clock interrupt.
(5) Scheduling of programs according to a pre-determined priority or on a time basis.
(6) Allocation of dynamic working store.
(7) Organiser calls, including -
program activation, suspension, termination
program to program message transfer
timing facilities
acquisition, relinquishing of working store and of data pages.
(8) Management of free page data chains.
(9) Provides interface between Interrupt and Task Programs and Device Control Programs.
There are three Device Control Programs used by the EPSS:
(1) Fast multiplexor channel/Processor interconnection channel DCP.
(2) Character line DCP.
(3) Drum backing store DCP.
The TFX/PIC device control program and the character line DCP are each designed as a framework of main modules upon which are built the device dependent and system dependent modules.
The TFX/PIC device control program comprises three main modules (fig. 5.):
(1) Driver to set up transfers.
(2) Interrupt processor.
(3) Basic timing and housekeeping.
Each main module has attached to it a sub-module for each type of line protocol for example, customer packet line, main network PSE-PSE line, and local PSU-PSU link.
The character line DCP comprises two main modules (fig. 6.):
(1) A line scanning program activated at a fixed clock time for example, every 20 milliseconds.
Only a proportion of the lines are scanned at each clock interval but all lines are scanned to a rate sufficient to read and transmit characters and dialling signals at the correct rates.
(2) Control program
This program has a number of main modules dealing with packet formatting, break down of packets, code conversion, call set up, call clearing and dial-up line allocation.
The control program is in two parts, the first acts as the interface between and is activated by the line scanning program and the routing processes. The second part is activated at a regular clock time and provides the timing and housekeeping functions for the device control program.
One of the main problems found while designing software for the EPSS is the large number of different protocols required for interfacing to various types of devices on the system, namely:
(1) Packet terminals connected by direct line.
(2) Direct character terminals connected by the BPO Datel service.
(3) Dial-up character terminals connected by PSTN.
(4) Dial-up character terminals connected by Telex.
(5) Other PSEs.
(6) Other PSUs on a PSE.
(7) The standby processor of a dual-processor PSU.
(8) Local Monitor and Control Point.
(9) Remote Monitor and Control Point.
(10) Master and standby drum backing stores for the storage of billing data and statistics.
(11) Virtual terminals within a PSU.
The implementers decided to use the packet formats and call protocols for all internal communication, with the exception of the control computer to standby computer interface. This decision had two major implications, first to increase the number of virtual terminals and second to use the inter-PSU links as main network routes thereby creating, in effect, a seven exchange network. Normal EPSS terminal numbers are allocated to these virtual terminals which are protected from access by unauthorised users by the closed user group facility. This approach allows great flexibility particularly in the use of the MCP control facilities and the use of backing store for the storage of billing and statistics. Should operating experience show the need to centralise or further disperse these functions the only change required is to change each PSUs routing table to route each packet to the new physical or virtual terminal.
All packets from local packet terminals and virtual terminals, after call validity checking, have a main network addition attached. These packets together with those from other PSEs, other PSUs and the local MCP are then routed to the appropriate output program (figure 7.).
Packets for delivery to packet terminals and virtual terminals on the PSU are validity checked by the destination call control program. This program also updates the destination terminal call record.
Each terminal on the EPSS has a terminal descriptor set up in a PSU (note only one copy of each terminal descriptor is held in a PSE).
The terminal descriptor holds details of the following and is identical for all types of terminals:
(1) Total buffer allocation and buffers used.
(2) Maximum number of buffers allowed per call.
(3) Upper and lower call label limits.
(4) Total labels allowed and in use.
(5) Interlock codes.
(6) Type and current status of terminal.
(7) Pointer to line descriptor.
(8) Pointer to call record chain.
All the parameters in the terminal descriptor, except the pointer to the call record chain, are set up when the terminal is brought into the EPSS. All can be dynamically changed from the Monitor and Control Point.
Each line, link or virtual terminal process connected to a PSU has a line descriptor. The content of the line descriptor differs for each type of connection. There is at least one terminal descriptor associated with each line.
All calls either to or from a terminal have a Call Record set up to describe the current state of the call, and to keep details of the agreed call parameters set up by the calling and called terminal for the call. Billing records are kept in core store, in packet format, for each call originating from the terminal.
Only on completion of a call or when the data bytes reach the maximum allowed in a packet is the billing data stored onto the two drum backing stores at the PSE.
Call records are formed into an ordered chain for each terminal. The order on the chain is determined by the terminal's call label. The data structure showing the relationship between the terminal descriptor, line descriptor and call records is shown in figure 8.
One of the problems directly resulting from the splitting of a PSE into two or more PSUs is that dial-up terminals using the PSTN or PSTxN services cannot of course, be guaranteed a connection to a particular PSU when dialling a PSE. Similarly there may not be a free dial-up port available to make a call from a PSU. This problem is overcome by holding for each dial-up line, on a PSU, a dummy terminal descriptor. When a dial-up terminal is connected a virtual process is activated to make a call to the PSU holding the terminal descriptor. The first response packet contains a copy of the terminal descriptor, assuming the terminal is not busy. The terminal is set busy in the PSU holding the master copy of the terminal descriptor to prevent further calls being made to the terminal.
An important feature of the software for the EPSS is the utilisation of the core store available for packets and call records. All free store is divided up into equal size pages, of 64 bytes in length. The first two bytes of each page are used as a pointer to the next page. Initially the pages are formed into four free page chains, one for each of the TFXs pind PIC channels and the remaining one for use by the software. Each of the channels has the ability to acquire pages from its own free page chain and to chain pages together to form packets. All pages are returned to the software controlled free page chain which also forms a reservoir of pages for 'topping up' of the channel chains when they reach predetermined low levels.
The routing philosophy devised for the EPSS is based on a few
simple rules -
(1) A route may connect two remote PSUs in different PSEs or two local PSUs within the same exchange.
(2) A route between two PSUs may comprise multiple circuits. This has the effect of widening the bandwidth of the route.
(3) Two attempts are made to transmit a packet on a circuit.
(4) If two attempts to transmit a packet on a particular circuit fail, then each other circuit comprising the route may be attempted twice.
(5) If a packet cannot be transmitted or fails two transmission attempts on each circuit of the 'primary route', then a 'secondary route' is selected if one is available.
(6) If the packet cannot be transmitted or fails two transmission attempts in each circuit of the 'secondary route' then it is discarded and a 'network information packet' is returned to the source terminal.
(7) One reason for a route being unavailable is if the number of packets waiting transmission exceeds a predefined queue length.
(8) Regardless of the route indicated in the routing table, no packet may be transmitted on the route by which it arrived.
(9) If the 'primary route' is the route by which the packet arrived then the 'secondary route' is tried.
Table 3 shows a possible interconnection plan for the EPSS and an example of the possible 'primary' and 'secondary' routes for the network, In the example when there is no direct route between two PSUs the internal route is chosen in preference to the external route, mainly because internal routes operate at up to eight times the transmission rate of the external routes. Only one row of the 'primary' and 'secondary' route tables is held by each PSU.
 | L1 | L2 | L3 | M1 | M2 | G1 | G2 |
| From | |||||||
| L1 | L | I1 | I3 | X1 | I1 | X3 | I3 |
| L2 | I1 | L | I2 | I1 | X2 | I1 | I2 |
| L3 | I3 | I2 | L | I3 | I2 | I3 | X4 |
| M1 | X1 | I4 | X1 | L | I4 | X5 | I4 |
| M2 | I1 | X2 | X2 | I4 | L | I4 | X6 |
| G1 | X3 | X3 | I5 | X5 | I5 | L | I5 |
| G2 | I5 | X4 | X4 | I5 | X6 | I4 | L |
| L1 | L2 | L3 | M1 | M2 | G1 | G2 |
| From | |||||||
| L1 | - | I3 | I2 | I2 | X1 | I3 | X3 |
| L2 | I2 | - | I1 | X2 | I1 | I2 | I1 |
| L3 | I2 | I2 | - | I2 | I3 | X4 | I3 |
| M1 | I4 | X1 | I4 | - | X5 | I4 | X5 |
| M2 | X2 | I4 | I4 | X6 | - | X6 | I4 |
| G1 | I5 | I5 | X3 | I5 | X5 | - | X5 |
| G2 | X4 | I5 | I5 | X6 | I5 | X6 | - |
| Note: | L = local |
| – = no route |
The high serviceability demanded of a PSE by the BPO specification presents some interesting problems to the designers of the control software for the dual processor PSU. Apart from being ready to take over control immediately upon the failure of the control processor, it must also be possible to bring an off-line standby processor back on-line and into the required state without affecting the service given by the control processor.
The approach adopted for the EPSS is to update the standby processor continuously to enable a record of all calls in progress, billing data, statistics and the current state of each line and terminal to be maintained. However, the actual packets are not transmitted to the standby processor.
The protocol used to communicate between the two processors does not use the packet formats or call protocols of the EPSS. In the event of a control computer failure the standby computer is in full control within one hundred milliseconds of detecting the failure. Packets in transmission when the changeover occurs are lost and must be retransmitted. It is also possible to lose a complete packet held in the core store of the failed computer, but as the sequence numbers of all packets received are known, customers are always informed of the loss by a network information packet.
Both processors run confidence checking programs at frequent intervals and after certain line interface equipment failures. Checks are made on power supplies, cooling fans and over-temperature detectors. Should a fault develop in the main modules of one of the computers it either goes off-line itself or is forced into an off-line state by the isolate/connect hardware.
The policy adopted for single computer PSUs is to continue for as long as possible even if the overall service is degraded. After orderly shutdown a PSU can be brought back on-line without loss of calls or other information.
Each Packet Switching Exchange is equipped with a Monitor Control Point (MCP), figure 9, any of which may be designated the system master. The main function of the MCP is to provide a man/system interface for the monitoring, recording and amending of system operational activity. It is designed to be unmanned except for the implementation of amendments and initiation of particular routines. Under unmanned conditions alarms are extended to manned points.
The MCP will also produce a station log of all PSE traffic together with an alarm log to record the incidence of PSE fault conditions. It is not possible for the PSE software and basic data lists to be changed from the MCP.
The MCP again makes use of an Argus 700E processor complete with 24K of core store. It is equipped with the usual range of peripherals for devices of this type, namely, a slow printer, a visual display unit and a four deck cassette tape system which
will be mainly used for program compilation. Digital outputs are used to drive extended alarms. Connection to the PSE is via a Processor Interconnection Channel (PIC) which forms a local link to each of the processors within a PSE.
The basic MCP software is the same as used in each PSU. A MCP comprises several virtual terminals each of which may control more than one process. For routing purposes the MCP is treated as an additional PSU by the other processors of the PSE, thus utilising the multiple high speed inter-processor links.
The loss of one or even all of the MCPs will not cause the failure of a PSE.
Using the latest Ferranti range of compatible processors, stores and input/output modules it has been possible to design a series of larger modules (Packet Switching Units) which may be combined to form the required type of Packet Switching Exchange of alternative serviceability and port access. Exchanges constructed to the relaxed specification are capable of enhancement to the full specification. This design concept, although simple, has resulted in a number of design problems, a few of which remain to be resolved. No doubt others will arise during the remaining development and later when the EPSS is fully operational.
The design of the PSE is essentially a hardware solution, the majority of the work being carried out by the intelligent packet line cards. This lessens the software requirement so easing software design.
Alternative, more technically attractive solutions were discarded because of the relatively short timescales imposed upon the project.
We believe that simple concepts lead to simple system designs| which are easily constructed, commissioned and possibly more important, readily understood. We expect the accuracy of this broad statement will be proved, or otherwise, during 1975.
Although the BPO are offering a wide variety of facilities to EPSS customers, some changes and additions to the specification have already been incorporated in the system. Some of these are the direct result of discussions at meetings of the Customer Liaison Group, between the BPO and intending EPSS customers. So far the system design has coped with these changes, but it remains to be seen whether the claims made by the designers about the flexibility of their system design stand up to future changes.
The authors wish to acknowledge the use of the following papers:
Data Communications - Developments in the United Kingdom. P.T.F. Kelly. UNKNOWN CITATION (IFIC General Assembly. October 1973).
Introduction to the British Post Office Experimental Packet Switching Service (EPSS). B.C. Belton and M.A. Smith.
The authors also wish to thank Mr.P.T.F. Kelly, Mr.R.C. Belton and Mr.S.J.R. Cole of the BPO for their help and assistance in the preparation of this paper and also Ferranti Limited for permission to publish.
This paper reflects the authors' views and are not necessarily those of the BPO.
References (1) The EPSS Customer Document.
