This paper describes REXPAC, the nationwide experimental packet switching data network being developed by CPqD, the research and development center of TELEBRAS, the holding company responsible for public telecommunications in Brazil. REXPAC uses internationally-standardized CCITT interfaces, following CPqD interpretations for X.3, X.25, X.28, X.29 and X.75. Its six backbone nodes with a centralized control system are connected by 9.6 arid 64 kbits/s full-duplex trunks. The packet switching exchange architecture is multiprocess/multiprocessor based and two different structures with different capacity characteristics have been chosen. The higher capacity version foresees future application in the national public data network.
I. INTRODUCTION
TELEBRAS is the holding company responsible 'for public telecommunications in Brazil and EMBRATEL is its subsidiary in charge of providing and operating the data communication services all over the country. The Data Communication Group of CPqD, The Research and Development Center of TELEBRAS, is in charge of designing and implementing a nationwide multi-purpose experimental packet switched network based on internationally standardized interfaces. This network, named REXPAC, represents the scientific and technical nucleus of the future Brazil-wide public data network that is already being specified by a group gathering TELEBRAS and EMBRATEL engineers. Although relying mostly on TELEBRAS, REXPAC might be regarded as a national joint-venture involving universities, industries and several other Brazilian corporations.
REXPAC actually constitutes a development laboratory for experiments and studies of packet switching technology envisaging its application to public data networks. Its direct fulfillment will be the network itself, but, more important, it is the opportunity offered to researchers all over the country for adequate scientific and technical progress in the data communications field.
This paper describes the architecture, interfaces, protocols and switching nodes of REXPAC.
II. NETWORK ARCHITECTURE
REXPAC will be the backbone for the local data networks currently being planned or developed by universities and R & D institutes and it supplies a natural interconnection structure for the TELEBRAS computing centers scattered throughout Brazil. REXPAC will also serve as an access to distributed database systems belonging to TELEBRAS and its various associates.
REXPAC is composed of six nodes located in Sao Paulo, Rio de Janeiro, Brasilia, Recife, Porto Alegre and Campinas. The necessary software and hardware facilities for a network control center are centered in the Campinas node.
The REXPAC node configuration is shown in Fig.l. The distribution of concentrators , line multiplexors and remote Packet Assembly/ Disassembly equipments (PAD) has been left to be decided later, according to demand requirements.
The communication trunks connecting Rio de Janeiro, Sao Paulo and Campinas are full-duplex 64 kbit/s links while, the Brasilia, Recife and Porto Alegre ones are full-duplex 9.6 kbit/s links. The implementation of a multilink communication structure between pairs of nodes is also planned.
A brief description of REXPAC elements represented in Fig. 2 and of its interface protocols is presented in the next item.
III. PROTOCOLS, FACILITIES AND SERVICES
The basic service provided to REXPAC users, and available for the communication among network elements, is the Virtual Call. All the interfaces follow CCITT Recommendations [1, 2, 3].
Users can access the network by means of Packet-mode Data Terminal Equipments (DTE-P ) connected directly to a node via full-duplex dedicated lines or, indirectly, via PADs, using character oriented synchronous or asynchronous Terminals (DTE-C).
The interface between a Data Circuit Terminating Equipment (DCE) and a DTE-P obeys the CCITT X.25 Recommendation and has been implemented according to a CPqD/TELEBRAS interpretation [4,5]. The physical interfaces (X.25, level 1) follow V.24 and X.21 bis. Link Access Procedure - Balanced Mode (LAPB/ X.25 level 2) is the only procedure available for DTE-P connections to REXPAC. The CCITT recommended facilities and services [6] to be offered by REXPAC are restricted to the essential ones.
A character oriented terminal (DTE-C) is connected to REXPAC via PAD equipment. All the functions associated to code conversions terminal control, character-to-packet adaptation and communication protocol management are performed by the PAD. The PAD is connected to a node as a standard DTE-P.
Physical connections of asynchronous DTE-Cs use full-duplex dedicated lines or the switched telephone network. The PAD/DTE-C interface follows the CCITT X.28 Recommendation. The X.20 bis option is the only physical interterface available at REXPAC for PAD / DTE-C connection.
The PAD functions are defined by Recommendation X.3. At first, only the functions defined as basic will be supported by REXPAC
Data exchange between a PAD and a remote DTE-P follows the CCITT X.29 Recommendation.
REXPAC implementation of CCITT X.3, X.28 and X.29 Recommendations obeys the CPqD/ TELEBRAS interpretations [7,8,9].
Synchronous DTE-Cs not adapted for packet communication will access REXPAC through PADs. These accesses are initially restricted to dedicated full-duplex 1200-2400 bit/s links and BSC terminals.
Interconnections between nodes follow the CCITT X.25 Recommendation. The physical couplings related to the 64 kbit/s links are V.36 compatible. The multilink structure and X.75 compatibility will be gradually introduced in REXPAC.
Permanent Virtual Circuits and Closed User Groups are standard facilities supplied by REXPAC. The use of these facilities is restricted to DTE-Ps. Permanent Virtual Circuit implementation is based on a network node path setup (Virtual Call) between predefined DTE-P pairs. A Virtual Call is automatically originated when the calling DTE-P is turned on.
The control and statistical information exchanged between network elements make use of a transport protocol (for message protection and consistency) and dedicated Permanent Virtual Circuits forming Closed User Groups.
IV. PACKET SWITCHING NODE
The layer structure of the X.25 protocol makes packet switching well suited to a multiprocessor implementation [10].
Link level processing involves real-time attention to line events (transmission, reception, etc.) and a strict time discipline for the logical tasks involved. Packet level processing, otherwise, is less restrictive in terms of real-time requirements, being more concerned with the subscriber and network table handling.
The REXPAC packet switching node is based on the multiprocess approach and its most relevant characteristics are: a multiprocessor architecture; a distributed bus structure; and a operating system responsible for message communication between processors and process synchronization.
1. Multiprocess/Multiprocessor Approach
The packet switching functions are grouped according to necessary or convenient parallel configurations and an adequate software entity called process is assigned to each group.
The communication rules between processes are defined in terms of
. specific messages exchanged between processes,
. consistency checks executed with respect to type, format and activation predicates for any transmitted or received message, and actions related to transmitted or received messages.
The process allocation to processors may occur during system initialization for some types of processes or during process generation for other ones.
The synchronization of and the message exchange between processes are based on SEND and WAIT primitives . A copy of the operating system is stored in every processor and it works in such a way that the physical localization of a given process is transparent to the application programs.
2. Packet Switching Exchange Implementation
The Packet Switching Exchange being developed at CPqD is composed of specialized process or modules communicating through a distributed bus structure. Two different bus structures are being considered, referring to different speed characteristics.
An exploratory packet switching exchange utilizing a duplicated ring structure as the basic communication path between processors is currently being implemented at CPqD to test the limitations of and permit experiments with a multiprocessor/multiprocess based technology for packet switching. The resulting medium capacity packet switching ex change will be used at the initial network nodes of REXPAC.
The multiprocessor based switching node with the ring structure (without showing the ring redundancies) is presented in Fig. 3.
The processes LHM, VCM, CCM, etc., defined below, are allocated to processors in such a way as to explore the natural existing parallelisms.
The ring has a total capacity of 1.6 M bit/s. The processor access to the ring is achieved through FIFO buffers filled or emptied via DMA.
The decisions about putting a message in the ring, or taking it out, are made independently in each processor by specially designed local controllers located in the ring interfaces .
A higher speed distributed bus structure is being analysed for the high capacity packet switching exchange. This bus is composed of FIFO buffers and a per-message switching structure (Fig. 4).
Each FIFO buffer is dedicated to a processor module as far as writing is concerned. After a message has been written, the buffer control, including clock signals, is completely liberated. A distributed polling mechanism transfers the message to the addressed processor.
This type of bus structure is rather simple and permits high level of parallelism ( N simultaneous transmissions, with N equal to the number of FIFO buffers in the bus) and complete independence of the communications between cooperating processors.
3. Process Definitions
In the exploratory packet switching exchange the following modules were defined:
(i) Link Handling Module (LHM): it includes procedures associated with X.25 levels 1 and 2;
(ii) Call Controller Module (CCM): it includes call setup, clearing and restarting procedures for logical channel associations
(iii) Virtual Circuit Module (VCM): it includes procedures for data switching from a logical channel to another one, after the call setup phase is completed;
(iv) Node Controller Module (NCM); responsible for the control of the switching node as a whole; and
(v) Peripheral Equipment Modules (PEM): responsible for the peripheral interface in general.
Each of these modules is associated at least to one process. The use of more than one process for the implementation of a given, function depends on the desired reliability characteristics.
4. Call Setup and Data Transfer Phases
The call setup procedure between two X. 25 terminals connected to the same Network Node at different Link Handling Modules is represented schematically in Fig. 5.
{Note: The green numbers in the following text refer to green numbers in Figure 5. The original paper used a convention which is difficult to reproduce in HTML. /RDM}
A frame (X.25, level 2) protected CALL REQUEST packet 1 is physically received and checked for link errors by LHM #1. This packet after type identification, is enveloped in internal message 2 and directed to the selected Call Controller Module (CCM). The message parameters include input link number, LHM number, CCM number, packet type identifier, logical channel number and the called Data Terminal Equipment (DTE) address. The correspondences between logical channel number and utilized CCM are kept in the LHM #1.
The tables with the network link allocations, LHMs and network addresses are kept in the CCMs. The CCMs also manage the logical channel utilization.
The addressed CCM determines the output link and the LHM # k corresponding to the addresed DTE. A message 3 with the INCOMING CALL packet is transferred to LHM #k. The message parameters include output link number, LHM number, packet type identifier and the selected logical channel number.
The INCOMING CALL packet is framed 4 and transferred to the called DTE.
The CALL CONNECTED packet 5 is routed through the LHM #k, CCM and LHM # 1 (6 , 7 ) to the calling DTE 11.
The CALL CONNECTED packet to the calling DTE is preceded by the preparation of the CCM selected Virtual Circuit Module 10 for handling the data transfer phase of the established virtual circuit. The VCM preparation. is implemented by transferring the information about the logical channels, links and LHMs involved. The LHMs are also informed about the VCM to be utilized to handle that virtual circuit (8,9 ).
These logical channels/LHMs/VCMs associations are used to switch the data packets through the network node during the data transfer phase. (12, 13 ).
V. CONCLUSION
REXPAC, an experimental data communication packet switched network, is a nationwide development laboratory for the progress of Tele-Informatics in Brazil and a scientific and technical nucleus for the future national public data network. A thorough description of aspects concerning its architecture, interfaces, protocols and switching nodes has been given.
VI. REFERENCES
[1] CCITT Recommendation X.25 "Interface between DTE and DCE for terminals operating in the packet mode on public data networks" [1976]
[2] CCIIT Recommendation X.25, "Draft Revised Recommendation of X.25 Introduction and Packet Level", COM VII - No. 439-E, November [1979]
[3] CCITT Recommendation X.25, "Proposed Revision to Level 1 and 2 of Recommendation X.25" COM VII - No. 374-E, October [1979]
[4] "TELEBRAS X.25 DTE/DCE Interface for Packet Mode Terminals on Public Data Networks-CCITT X.25/Level 2 Interpretation", CPqD/TELEBRAS Internal Report, May [1980]
[5] "TELEBRAS X.25 DTE/DCE Interface Packet Mode Terminals on Public Data Networks-CCITT X.25/Level 3 Interpretation", CPqD/ TELEBRAS Internal Report, May [1980]
[6] CCITT Recommendation X.2, "Proposed Revision to CCITT Recommendation X.2 and Question 2/VII, COM VII- No-414-E, November [1979]
[7] "TELEBRAS X.3 Packet Assembly/Disassembly (PAD) on Public Data Networks-CCITT X.3 Interpretation", CPqD/TELEBRAS Internal Report, May [1980]
[8] "TELEBRAS X.28 DTE/DCE Interface for Start-Stop Terminal for PAD Access on Public Data Networks-CCITT X.28 Interpretation", CPqD/TELEBRAS Internal Report, June [1980]
[9] "TELEBRAS X.29 Procedures for the Exchange of Control Information and User Data Between a PAD Facility and a Packet Mode DTE or Another PAD-CCITT X.29 Interpretation", CPqD/TELEBRAS Internal Report, June [1980]
[10] M.A. Bergamo and R.Gadelha P., " The Architecture of the Telebras Packet Switching Node", presented at INTELCOM 80, Rio de Janeiro, Brazil.
[11] M.A.Bergamo,"Design of Data Communication Packet Switched Data Networks", XII Congresso Nacional de Processamento de Dados-SUCESU, pp. 623-640, Sao Paulo, October [1979]
[12] E.G. Grizendi, "An Interface for Public Packet Switching Data Networks", XII Congresso Nacional de Processamento de Dados-SUCESU, pp.649-658, Sao Paulo, October 1979.
Marcos Antonio Bergamo received the B.S. degree in electrical engineering from the Technological Institute of Aeronautics (ITA), Sao Jose dos Campos, SP, Brazil, in 1973, the M.S. degree in digital communications from the Institute for Spacial Research (INPE), Sao Jose dos Campos, SP, Brazil, in 1976, and the M.S. degree in electrical engineering from the University of California, Los Angeles, in 1977. From 1974 to 1976 he was a researcher at INPE, where he worked on digital transmission and image digitalization . In 1977, as a digital communication system engineer at LinCom Corporation, Los Angeles, he worked on developments related to the space shuttle communication system. In 1978, at EMBRATEL, the corporation responsible for providing and operating interstate, telex and data communication services in Brazil, he worked on market evaluation and analysis of technological alternatives for the switched data communication services in Brazil. Since March 1979, when he joined the data communication group of the Research and Development Center (CPqD) of TELEBRAS, the holding corporation responsible for public telecommunications in Brazil, he has been working on an experimental packet switching data network (REXPAC). He is currently responsible for the development of a packet switched data exchange for the Brazilian public data network. Mr. Bergamo is a member of the IEEE Communications Society.
Antonio Salles Campos received the B.S. and M.S. degrees in electrical engineering from the Technological Institute of Aeronautics (ITA), Sao Jose dos Campos, SP, Brazil, in 1962 and 1967, respectively, and the doctoral degree in electrical engineering from the University of Sao Paulo, SP, Brazil, in 1968. From January 1963 to December 1978 he was a Professor of Electrical Engineering at ITA, serving as Head of the Electrical Engineering Department from 1970 to 1977 and as Supervisor of Research and Development Projects during 1978. He is currently working in Campinas, SP, Brazil, where he is in charge of the data communications group of the Research and Development Center (CPqD) of TELEBRAS the holding corporation responsible for public communications in Brazil. Dr. Salles has published in the areas of system theory and computer communications and is a member of the Brazilian Societies of Operations Research (SOBRAPO) Simulation (SBS), Automation (SBA), and of the Brazilian Committee of Telephony and Telegraphy (CBTT).