PAXNET – A Public X.25 Service in Denmark

Ole Brun Madsen, Bent Bæk Jensen

► To cite this version:

Ole Brun Madsen, Bent Bæk Jensen. PAXNET – A Public X.25 Service in Denmark. 4th History of Nordic Computing (HiNC4), Aug 2014, Copenhagen, Denmark. pp.181-188, 10.1007/978-3-319-17145-6_20. hal-01301408

HAL Id: hal-01301408

https://inria.hal.science/hal-01301408

Submitted on 12 Apr 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# PAXNET – a Public X.25 Service in Denmark

Ole Brun Madsen¹ and Bent Bæk Jensen²

¹Prof. emeritus, Aalborg University
obm@es.aau.dk

²IT manager (former) L.M. Ericsson
bentbaekjensen@gmail.com

<figure><img src="image_2.png" /></figure>

**Abstract.** PAXNET was one of the first full scale ISO OSI implementations in the world. PAXNET was in operation from 1983 to 2006 and served the operating telephone companies in Denmark with a general data communications infra-structure. PAXNET also provided a public X.25 service and was furthermore carrier network for the public alarm service with more than 50.000 customers.

## 1 Introduction

PAXNET is the name of a data communication development project running primarily from 1980 to 1992. PAXNET was also the name of a physical network covering Denmark, Faroe Islands and Greenland providing a number of services including X.25 and value added services.

The PAXNET project originally started as a co-operation between:

RECAU (The Regional Computing Center at the University of Aarhus)

Regnecentralen (Danish computer manufacturer)

JTAS (The Jutland Operating Telephone Company)

KTAS (The Copenhagen Operating Telephone Company)

The original purpose of the project was to design and develop a network that could solve some of the data communications problems present at JTAS and KTAS. RECAU represented the Centernet Project, which aimed at interconnecting the three regional computing centers at the University of Copenhagen, the Technical University (DTU) and the University of Aarhus.

Later it was politically decided that PAXNET also should provide a public X.25 service. Furthermore, it opened up for providing non-standardized value added services.

The design and development of PAXNET was based on international standards mainly the ISO OSI model, which was first published in 1978. Only where international standards were not available manufacturer specific protocols were used.
A more detailed description of PAXNET can be found in [1].

This presentation describes in some details the implementation of the OSI 7 layer protocol stack, the PAXNET connectivity and the network management system. Furthermore, the specific X.25 service and network are described, and the paper ends reflecting on “the lessons learned” in a project that started, when PC’s, LAN and the internet did not exist, and was finalized just before the Internet and TCP/IP took over. In the PAXNET life-time ISDN was born and died again. ATM came up, but never became the success it may have deserved.

## 2 PAXNET and International Standards

From the beginning it was clear that PAXNET should adhere to international standards wherever possible. Overall PAXNET should be implemented according to the ISO Open Systems Interconnection model (see figure 1) that was finalized in 1978.

<figure><img src="image_3.png" /><figcaption>Fig. 1. The ISO OSI model</figcaption></figure>

The decision was also taken that the data transport system (layer 1-3) should be based on the X.25 recommendation from CCITT.

When we began to design and implement NMS, the network management system, the standards were not in place, so we made our own design (illustrated in figure 2).

<figure><img src="image_4.png" /><figcaption>Fig. 2. The NMS architecture</figcaption></figure>
# 3 Implementation of the “OSI Tower”

The OSI model is not an implementation guide. This is specifically written in the standard. OSI only describes how open systems can communicate. Therefore, we needed ourselves to architect how to implement the seven layers.

## 3.1 Data Transport (layer 1-3).

X.25 is an interface protocol, and it does not describe how data are transferred from sender to receiver. We designed a system based on datagrams and an internal protocol, called the LIC protocol (see figure 3).

The LIC protocol was created to take care of faulty transmission lines, and the datagram network was responsible for sending data packets from sender to receiver, based on an advanced routing mechanism.

<figure><img src="image_5.png" /><figcaption>Fig. 3. The data transport system</figcaption></figure>

## 3.2 Upper Layers (layer 4-6)

In this context layer 4-6 is of little interest. We will only mention two features that were a bit unique: the session layer Session Control Center (SCC) and the virtual terminal in layer 6.

The SCC took care of the task to identify users, to check the validity of the call and to find the physical address of the receiver. Much the same as DNS today is doing in the Internet.

The other unique feature was the virtual terminal (part of the presentation layer (layer 6)). The virtual terminal concept solved the problem that all physical terminals could be used to access all applications. This was actually one of the main goals for PAXNET.

# 4 Interfaces to PAXNET

One of the main design criteria was that many interfaces to access the network should
be available, not least the ability to connect terminals and hosts (and thus terminal access to applications). The overall picture is shown in figure 4.

The following main terminal and host interfaces were available:

- X.25 and X.28 (X.32)

- Terminals (VT100, ECMA48, IBM 327x BSC)

- Host interfaces to RC8000, CDC Cyber, IBM 30XX, Honeywell Bull DPS8 and Tandem

<figure><img src="image_6.png" /><figcaption>Fig. 4. Interfaces to PAXNET</figcaption></figure>

# 5 Network Management System (NMS)

It was clear from the start of the project that network management and control was equally as important as the communication part. However, no standards were in place, so we did our own unique design as depicted on figure 2.

Actually, the network management group in PAXNET gave a lot of input to the standardization process of NMS in ISO.

To pinpoint just one unique part of the NMS system, let us mention that a very important feature in the user interface was a graphical interface. This was a very early usage of graphics in a real time environment.

# 6 PAXNET as a Public Service Provider

Until the telecom liberalization process occurred in the 1980s all public data communication services in Denmark were delivered by the PT&T. This included modems for leased lines, X.21 (DATEX) and X.25 (DATAPAK). But already in 1981 PAXNET had its X.25 interface ready, and this started a political discussion why this couldn't become a public service. It took a few years to reach a conclusion, but from January 1st 1987 PAXNET went public and provided the following services:

- X.25 packet switch access
- Access for character oriented terminals via X.3, X.28 and X.29 protocols

- Optional services via the X.2 recommendation (like closed user groups and reverse charging)

A year later, this was supplemented with further services:

- X.32 (X.25 access via "dial up")

- X.400 (standardized electronic mail)

- FTAM (file transfer)

The PAXNET group consisted mainly of development people so we had no problems with the technical part. However much more than technical knowledge is needed when you are to provide a service to external customers. Data communications was a new area of business for the operating telephone companies so it took a while to get all administrative procedures in place like ordering, billing and being able to advise customers.

Before PAXNET went public, the PT&T had offered an X.25 service which we found were much too expensive. We managed to cut the price level with about 30%, but even with this cost reduction, the X.25 service never became a huge success.

<figure><img src="image_7.png" /><figcaption>Fig. 5. Computer World's comment on X.25 charging</figcaption></figure>

In 1991 there were around 5.000 customers using X.25 and X.28, but competition came from Frame Relay and other data communication services, and the number of customers decreased. However, X.25 was available until 2004, because internationally X.25 provided the best connectivity.

# 7 Experiences and Lessons Learned

This section sketches some of the most important decisions and findings in the PAXNET project.

## 7.1 Real Time Pascal (RTP)

The PAXNET communication software was unique in the sense that everything was
programmed in a high-level language called Real Time Pascal. Basically RTP was PASCAL extended with processes and process communications. The language was developed at the University of Aarhus.

The target machines (network nodes) for the communication software did not have assembler coding as an option, so there was no alternative to RTP. Even drivers were programmed in RTP.

The compiler was running on an RC8000 (a midsize computer from Regnecentralen (RC)) and delivered re-locatable code in a file which could be downloaded to the target node.

The choice of RTP was highly successful as it gave very readable programs and thus made error corrections quite easy. Furthermore, it was also easier to extend the software with new features.

## 7.2 Own Development in Contrast to Buying

Quite early in the project, it was decided to develop all software from scratch instead of trying to buy off-the-shelf products. Regnecentralen had a product, RC-net, that they wanted us to buy, but we found it was based on a hardware platform not suited for the purpose and the expectations of a future-proof system.

On the other hand, it was a challenge to start from scratch, as data communication was not something that was taught on the universities. Even if we had a skilled group of IT people there was much to learn about real time systems, protocols, services, network management and how all these elements interact.

So one outcome of the whole project was that more than 100 people were well educated in data communication and management of a big data network in 24 by 7 operation.

## 7.3 The Co-operation Model

We believe that a unique co-operation model existed between the four partners:

- The private computer manufacturer (Regnecentralen)

- The two public monopolies (JTAS and KTAS)

- The University (represented by RECAU)

RC was the manufacturer and delivered most of the software. JTAS, KTAS and the Centernet project had made a joint financial model to pay RC. Later, when Centernet was closed down, the cost was split equally between JTAS and KTAS. The two other operating telephone companies The Funen Operating Telephone Company (FT) and Tele Sønderjylland (TS) entered the co-operation but did not provide resources to the development.

The project was organized with a project manager group and two technical committees (one taking care of NMS and one taking care of more general technical problems). RC sometimes had a rough time being both a manufacturer and a partner. However, we managed to overcome these problems even if RC was legally bounded by a contract.
## 7.4 PAXNET as a Product to Sell Abroad

The operating telephone companies had a joint company called Danish Telecom International (DTI). The purpose of DTI was to sell some of the unique solutions, that were developed and used by the Danish telephone companies. This also included PAXNET. A huge effort was invested trying to sell it as a public network to PT&T's around the world. Even if we came close in Greece, Thailand and a few other countries, we never managed to sell the system abroad.

RC also did an effort to make PAXNET a product and sell it both on the domestic and on the external market, but with no success. However, one exception should be mentioned. The EU established the IXI network in 1990 covering 18 EU countries. The nodes in this network were PAXNET nodes bought from RC.

After the creation of Tele Denmark, most of the development activities were closed down, and the maintenance was handed over to Telebit. Telebit was a company started on the ruins of the closure of Regnecentralen, and a lot of the PAXNET team from RC and JTAS got jobs at Telebit.

## 7.5 How to Manage the Technological Changes that Occurred?

Many technological break-throughs had impact on the development of PAXNET during the years, let us just touch on a few.

### Transmission capacity and new technologies like ISDN and ATM

In the beginning of the 1980s, communication lines were slow (max. 64KBPS) and the error rate quite high. Transmission errors were handled either by the HDLC protocol or by the LIC module. Later everything became digital, the speed went up, and everything improved.

When ISDN was introduced there was a strong belief among telephone engineers that all special networks like PAXNET would disappear. Everything would be integrated in ISDN, the Integrated Services Digital Network. This did not happen – the best you can say about ISDN is that it gave us a 128 KBPS digital access link. The PAXNET node contained an ISDN access card that could directly benefit from this. ATM never played a role as a user interface.

### PC's and LAN's

In the mid 1980s, we started to move away from terminals and terminal clusters. Instead, LAN and PC's became the dominant technology. For PAXNET it was a quite easy to adapt to this trend. The only thing we needed to implement was an interface to the most important LAN technologies (at that time it was Ethernet, Token Ring and some broadband LANs).

The introduction of PC's and LAN's increased the traffic that the switching nodes should manage, but the technological improvements also increased the capacity of the switching nodes, so the traffic growth never became a problem.
## TCP/IP (Internet)

In the early 1990s, TCP/IP began to be an important player in the data communication environment. This became the end for the OSI era including X.25.

OSI contributed strongly to the structuring and formalizing of the description of protocols, protocol stacks and related services. However layer 5 and 6 were fairly complicated and created a high overhead. With TCP/IP and the related applications, it was figured out that the functionality of the OSI upper layers could be solved in a simpler way.

## 7.6 danNet and Comlink

In 1987/88 IBM and KTAS established a joint venture, danNet, in order to provide value added services on top of the X.25 service of PAXNET. In 1988, JTAS established a competitor to danNet called Comlink with the same goal as danNet.

KTAS decided to use many of the competences built up in PAXNET to support the design and development of the danNet product portfolio. Hence most of the key persons in the KTAS part of PAXNET were transferred to danNet.

When Tele Danmark was established in 1992, Comlink and danNet were combined in one company with danNet as the leading company. DanNet was later sold for a few billion DKK and got the name MACH. This way KTAS and JTAS indirectly benefitted from the PAXNET project.

## 8 Final Remarks

PAXNET fulfilled its goals – it solved the internal data communications problems that were present in the IT departments of the telephone companies. All internal users were connected (2500+), all remote printers were connected (400+), and PAXNET was also the carrier for much administrative traffic to/from the telephone exchanges. Furthermore, PAXNET became a public X.25 service provider with approximately 5.000 customers in 1991, and, not least, PAXNET became the carrier network for the public alarm service with about 50.000 customers.

Finally, you can ask: Did JTAS and KTAS get value for their money? It is difficult to measure directly today, but according to one of the financial directors in Tele Denmark it ended up being a really good business. At the same time, PAXNET contributed to the education of quite many people in data communications, skills they have been using in the remaining of their career.

We also believe that most of the more than a hundred people involved in development, design, operations and physical establishment of the network remember it as something special.
References

1. Bent Bæk Jensen and Ole Brun Madsen: *PAXNET*. Books on Demand, GmbH ISBN 978-87-7145-563-2 (2014)