ARCHITECTURE, PROTOCOLS AND PERFORMANCE OF RETD
LUIS LAVANDERA
CTNE SPAIN

SYNOPSIS

RETD is a nationwide public data network designed and operated by CTNE, the company responsible for telecommunications in Spain.

A general overview of RETD's protocols is expounded throughout this paper, along with the hierarchical organization of the interfaces with their orthography, semantics and syntax. The topics focused on performances and operative experience, gained along nine years of commercial operation, is complemented by the grade of service and the total traffic of RETD.

New projects are cited including the third-generation switches to conclude by giving impressions about the impact of public data networks on user data communication systems.

Keywords:Orthography, semantics, syntax, protocol, performances, grade of service, third-generation equipments.

1. INTRODUCTION

With the enormous growth experienced by computer processing since the decade of the 60's, the urgent need of preparing adequate transmission media emerged, which would make possible data interchange among different computer systems. Such a necessity caused the implementation of private networks by several organizations to meet their own specific requirements.

Apparent to everyone, the high implementation and maintenance cost that such a solution imposed on the users and, furthermore, due to the notable fact of the incompatibility of the different data terminal equipments, the National Telephone Company of Spain (CTNE) took the decision to implement a Special Data Transmission Network (RETD), in spite of the multiple negative opinions that specialized articles expressed at that time, contending that to design a public data network was not justifiable.

The technology chosen for RETD was packet - switching, and from its inauguration in November 1971 it began to serve publicly in all the national geographical areas in such a way that any user, large or small, would have access to the network, independently of the type of application to be performed.

It is not my intention to spotlight the inherent concepts to packet switching or to extol its peculiarities derived from the dynamic allocation of resources. On the contrary, I consider more interesting, after almost one decade of commercial operation, to focus this paper on the outstanding aspects and projects of RETD.

2. USER INTERFACES

A large part of the gain derived from packet switching is based upon a well organized management system of centres' intelligence and upon the communication protocols constituting the network interfaces.

The term protocol is generally used to refer to a concrete language which makes the interaction between a level and its peers of another system possible. It will therefore enclose the orthography, the semantics and the syntax of the interface.

There are two types of device-independent Interfaces wholly defined in the functional specifications of RETD. Both of them, based upon the virtual circuit technique, are known as: RSAN and X25.

3. RSAN INTERFACE

It was entirely designed by CTNE and started to work as the time the RETD was inaugurated, that is to say, November 1971. At that time, the data - transmission field was not so developed as to attempt a task at international standardization level. This happened several years later, as we will see afterwards.

Well then, RSAN has reached, and will keep on reaching, with a vengeance, the aim which it was designed for. This goal was to achieve a full grade of standardization at national level, upon being the only interface supported for connecting computers through the RETD at that time.

After many years of commercial operation, and developed in very different types of computers which daily access to the public date network in order to interchange information belonging to the financial, industrial and social spheres, we can consider the RSAN as a very debugged and robust interface that has had the double merit to offer a very good grade of service and to provide the CTNE with an experience in operation, analysis and specification from which its synonymous X25 has benefited a great deal.

Let us briefly describe hereunder some important features of RSAN.

3.1. STRUCTURAL SUBLEVEL

It is the part where the "Orthography" of the interface is specified. This sublevel then establishes the basic rules to transfer signalling and data by defining the structure and delimiting -field, providing transparency and detecting transmission errors. The orthography of RSAN fits the following frame format:

3.2. LOGICAL SUBLEVEL

It is the "semantics" of the interface. It specifies hence the elements of language suitable to accomplish a correct signalling and data transfer. These are: Control Packets (PC) and Service Blocks (BS).

Control packets hold information concerning the internal function of user and network centres, as well as the circuits constituting the link. Service packets hold information related to the control of asynchronous terminals, such as a status report or the action to take on a terminal, etc. Control packets and service blocks can be generated both by network centres and by subscriber computers.

We will expound hereunder the control and service packets repertory.

- CONTROL PACKETS REPERTORY -

PC 0 Circuit Testing

PC 2 Restart Confirmation

PC 3 Call Request or opening of a group of logical channels

PC 4 Call Connected (Group of L.C.)or Clear Confirmation

PC 5 Reset, Clear and Restart Request (Local procedure error)

PC 6 Restart Indication (Network Operational)

PC 7 Clear Request (Group of L.C.)

PC 8 Restart Request

PC 9 Report on a circuit out-of-service condition

PC 11 Report on the need for restart because of a route failure (Multiline protocol)

PC 13 Clear Indication because of a logical channel group out-of-service condition (inactivity of a CAR)

PC 14 Reset or Clear Indication (inactivity of a Host)

PC 15 Receive Not Ready

PC 16 Receive Ready

- SERVICE PACKETS REPERTORY -

BS 1 Opening of a terminal on data reception and transmission

BS 2 Admission of input from a terminal

BS 3 Stopping of input from a terminal

BS 4 Logical closing of a terminal (clear request of a logical channel)

BS 5 Inquiry about the status of a terminal

BS 6 Report on the status of a terminal

BS 7 Reset Request

BS 8 Report on transmission progress (Dynamically selected end-to-end flow control)

BS 9 Clear Request (Out-of-service)

BS 10 Reset Confirmation, Clear Confirmation or Call Connect

BS 11 Reset Indication

Both control packets and service packets hold, besides these basic meanings, different options about which I invite the curious reader to collect information from RETD's specifications.

3.3. PROCEDURAL SUBLEVEL

It is the part that specifies the "syntax" of the interface. Such a sublevel provides then the legal sequences of commands and responses which must take place for a correct data flow interchange. To avoid an excessively long presentation, I will not enter into detail about the syntax of control and service packets. Needless to say, however, the more interested reader can find exhaustive information in RETD's specifications.

4. X25 INTERFACE

Once the mystery that hung over packet switching had been clarified, and after the interest shown by several countries during the period 74-76, it was felt that there were enough incentives to attempt the task of standardizing an interface for connecting computers to data public networks according to the above-mentioned technology. Such a task was developed inside the Commission VII of CCITT and, on May 2nd,, 1976, a recommendation commonly known as X25 was submitted for approval.

However, perhaps owing to the spread of the work, to the accelerated conclusion of agreements and to the lack of experience in commercial operation with a data network, a period no longer than six months elapsed before the first modifications of X25 were introduced. To tell the truth, both in data transmission and in ecology hasty and premature decisions always lead to new statements.

Thus, from the first correction at network control level, effected in November, 1976, and the adoption of a new mode of operation for link control in - April, 77, up to the recent resolution of the conflict associated with the meaning of the interface dragged along from that time, X25 has been outlined and strengthened. It will be presented again in November, 1980, for another approval that we envisage more stable this time.

X25 specifies two link control procedures, called LAP and LAP B. This, which is even against the rational spirit that gives life to every standardization task, is due to the fact that the primitive LAP procedure is still being dragged along for the sake of a very small population of terminals.

The first text specified for LAP B was deficient and unclear due mainly to the manner of reaching a compromise hypothecating grades of freedom at the time of choosing solutions so that any addition would be qualified as an extension rather than a change. This introduced ambiguities such as the assignment of more than one meaning to a response, or unjustifiable restrictions related to the set-up, disconnect and supervisory functions of the link; the only reason for dragging along such deficiencies being a hypothetical population of terminals that without a doubt, are not much more than a few ten.

The development of the link control procedure for X75 made those facts apparent, and lead to the necessary modifications to bring the link control procedure in line with both X25 and X75; the rational behind that encompassing obvious reasons such as the elimination of ambiguities as well as CTNE contributed actively to improve the LAP B procedure in the CCITT so that in May of 1979 the LAP B procedure was finally remodeled eliminating restrictions and deficiencies, its outstanding characteristics being a fully symmetrical procedure.

Likewise, RETD does not support the LAP procedure which, just after the moment of its birth, became obsolete.

5. PERFORMANCE AND OPERATIVE EXPERIENCE OF RETD

The cornerstone upon which the entire network design revolves around is the performance achieved starting train certain parameters. The performance gives us the network's capacity to face certain requirements. According to the foresaid, RETD is designed to stand user's applications which are critical either in response time (Real Time) or in -throughput (Bulk data transfer). Let us cite some significant performance measurements about the Grade of Service (GOS) in RETD.

5.1. GRADE OF SERVICE FOR NETWORK CONGESTION

Depending on whether the virtual circuits are switched or permanent, and whether the logical channel is in data phase or not, we have:

- REJECTED VIRTUAL CALL

The GOS expresses the-possibility that, during a second of the peak hour, a data terminal equipment cannot establish a new call due to network congestion.

Prob (Call Reject for Congestion) ≤ 10-2

- SET-UP VIRTUAL CALL

The GOS expresses the probability that, during a second of the peak hour, a call in data phase be cleared for network congestion.

Prob (Clear Set-up Call for Congestion) ≤ 2*10-6

- PERMANENT VIRTUAL CIRCUIT

The GOS expresses the probability that, during a second of the peak hour, a call is reset due to network congestion.

Prob (Reset due to Congestion) ≤ 2*10-6

- MULTICHANNELS

The GOS expresses the possibility of the number of restarts owing to network congestion, during a certain time.

Prob ((Number of restarts during T)≤1)≤ 5*10-2 ; T = 1 week
{sic}

5.2. GRADE OF SERVICE FOR TRANSIT TIME

The transit time is defined as the time elapsing when transferring a packet through RETD from the input network centre to the output network centre.

Prob (Tt≥T) ≤ 5*10-2 Transit time; T = 2 s.

As one can see, the delay added by the network equipments is perfectly bearable for the most exigent conversational applications.

The transferring time for packet and network centre is:

Prob (Tt ≥ 300 ms) ≤ 10-1

5.3. GRADE OF SERVICE FOR CALL SET-UP

The GOS expresses the probability that, during the peak hour, the time needed to set up a call will be greater than a certain parameter.

Prob (Tell<t) ≤5*10-2  Tell=Call Set-up Time; t = 3 s.

5.4. TOTAL TRAFFIC AND OTHER MISCELLANEOUS FEATURES

The statistics about RETD show that in a typical day:

- 3,164,000 transactions are sent and processed
- It carries around 510 million characters
- The average throughput is 234 Kbits/s.
- At the height of the peak hour the throughput can get 256 Kbits/s.
- It services about 40 subscriber hosts, and 9,257 terminals
- It has about 12,000 access ports available
- It uses about 115 minicomputers

6. NEW DEVELOPMENTS

There are several projects in a very advanced stage of development to maintain RETD in the state of-the-art. The most Important ones deal with:

- Development and production of the new network centres.
- Providing the SATEC II (Coded Alarm Public Service)
- Supporting for transaction telephone
- Implementing new text communication services
- Message handling facilities

6.1. DEVELOPMENT OF NEW NETWORK CENTRES

According to CTNE's specifications and design, the new telecommunications-oriented computers (TESYS 5 and TESYS 1) are in a very advanced manufacturing and installation state. The new centres are based on multimicroprocessor advanced technology and all the functions to be effected by the system are supported by a unique type of subset of - process unit, a fact which bestows a great reliability to the software design, as well as to the hardware maintenance. The architectural design is completely modular, permitting the addition of new subsystems according to the demand of new ports.

Some figures about TESYS 5 are:

- LINES CONNEXION CAPACITY

- 64 high speed (up to 64 Kbps), or

- 640 synchronous full-duplex (up to 9,600 bps), or

- 1,280 asynchronous (up to 1,200 bps), or

- Different combinations

- TRAFFIC HANDLING CAPACITY

It can get up to 2.4 Mbps.

- CALLS

Up to 900,000 communications at the busy hour.

- POWER SUPPLY

Telephone type (-48 V d.c.) for both TESYS 5 and TESYS 1.

Some figures about TESYS 1:

- CONNEXION CAPACITY

- 2 high speed lines (up to 64 Kbps), or

- 20 synchronous full-duplex lines(up to 9,600 bps), or

- 40 asynchronous lines (up to 1,200 bps), or

- Different combinations

- TRAFFIC

The traffic handling capacity can get up to 75 Kbps.

- CALLS

Up to 26,000 communications at the busy hour.

Fig.1 shows very schematically the TESYS configuration.

6.2.THE CODED ALARM PUBLIC SERVICE (SATEC II)

It is a service to transmit coded alarms through RETD at a national level, and it is intended to serve primarily any type of institution concerned with security,

6.3. THE TRANSACTION TELEPHONE

This term is generally used as a synonym of a new credit card generation, and is a service oriented to connect via RETD the banks' host computers with point of sale terminals spread over small and large stores. The transaction telephone is intended to apply primarily to a SPAIN inland service.

6.4. NEW TEXT COMMUNICATION SERVICE

The Teletex, Videotex and Digital Facsimile are included as such. Pilot projects have been established and is the intention of CTNE to have available the videotex system for the football (soccer) world championship (Summer 1982).

6.5. MESSAGE HANDLING FACILITIES

The present message switching service operated by CTNE since August of 1977 as an added value of RETD is accessed by 1,300 DTE's from the 9,527 that RETD has now in operation.

It is, however, the intention of CTNE to enhance such a system application in order to make available a wider range of facilities to the user. As such CTNE is actively collaborating in the new question 5/VII that, we expect, will receive a great support from the data networks community.

7. CONCLUSION

Before RETD started to operate as a public network on a national basis, users were forced to implement solutions to fulfil momentary needs on their own. These solutions involved facing many problems on several fronts, such as leasing lines from CTNE, renting or buying modems, multiplexors or concentrators from different and, hence, independent suppliers, designing software to control the network and monitoring facilities from software consultings, as well as personnel for maintenance.

With the availability of public data networks, the user has been relieved of such a burden, with consequent savings in time, endeavour and money, having solely to bring about the interface development to connect to the network.