OSIRIDE: state of the art and future developments

359

OSIRIDE: State of the Art and Future Developments F. C A N E S C H I ,

E. G R E G O R I

a n d L. L E N Z I N I

CNUCE, Institute of the Italian National Research Council, Via S. Maria 36, 56100 Pisa, Italy

OSIRIDE (OSI over Heterogeneous Italian Data Network) is the result of the efforts of a number of persons mainly from the Italian National Research Council and industries. The first phase of OSIRIDE (named OSIRIDE/I), dealing with the formal specifications production of a number of protocols, was completed on schedule and in accordance with the initial objectives. The second phase of the project (named OSIRIDE/II), dealing with implementation, started at the beginning of the 1984. Previous papers have already introduced OSIRIDE, its goals, participants and technical choices. However, for the sake of understandability, a brief resum6 of the whole project is dealt with in the first sections: for more information the interested reader is referred to the papers cited.

1. Introduction The policy followed in the last few years by the Italian National Research Council (Consiglio Nazionale delle Ricerche - CNR) on the distribution o f c o m p u t e r facilities h a s b e e n b a s e d o n t h e following choices: -

-

Computing power distribution - The growing demand by national scientific/technical users for computer facilities has made the institution of CNR computer centers indispensable in areas where users exceed a certain critical number. Differentiation of hardware - CNR has maint a i n e d a p o s i t i o n o f e q u i d i s t a n c e i n its r e l a t i o n ship with computer manufacturers, encouraging in this way heterogeneous choices (from the

Keywords: OSIRIDE, Protocols, Italy, OSI, Computer Net-

work

Enrico Gregori received an Electronic Engeneer Diploma from the University of Pisa in 1980. In the same year he joined C.N.R. (the Italian National Research Council) and started to work in the C.N.U.C.E institute as a research collaborator. Since the beginning his activity has been highly related with the Open Systems Interconnecfion standardization work. He was involved both in the definition of some OSI services and protocols and in the simulation of Communication proto-

Dr. Fausto Caneschi has been working in the field of computer hetworks since 1977, when he joined the National Research Council of Italy with a fellowship. After one year at IIASA (International Institute for Applied Systems Analysis) of Vienna, Austria, he has been appointed as responsible for the development of the Italian academic network RPCNET. He was then involved in the OSIRIDE project since its beginning, and was appointed as Italian representative in the ISO standardization committees. He is now leading the ISO group responsible for the formal specification of the Session Layer in LOTOS, a formal description technique developed within ISO. Dr. Caneschi's main interests lie in the OSI upper layer protocols, and the application of formal description techniques.

North-Holland Computer Standards & Interfaces 5 (1986) 359-364

cols. He actively partecipated in the OSI Working Groups dealing with the transport Layer and with OSI management. He is currently a research visitor at the IBM Zurich Research Laboratory where he is working on a possible solution of an OSI-compatible Local Area Network environment. L. Lenzini graduated in Physics at the University of Pisa and joined CNUCE - an Institute of the Italian National Research Council (CNR)- in 1970. From mid-1974 to 1978, he was the project leader of RPCNET, a distributed packet switching network linking Italian Universities and Research Institutions. From 1979 to 1983 he was leader of the group working on the design of the STELLA (Satellite Transmission Experiment Linking Laboratories) international project. From 1982 he has bee~ leading the OSIRIDE project. From 1985 he is the Project Coordinator of the CNR Strategic Projects on Networking. He is also giving a course on OSI at the Department of Computer Science of the University of Pisa.

0920-5489/86/$3.50 © 1986, Elsevier Science Publishers B.V. (North-Holland)

360

-

F. C a n e s c h i et al. / O S I R I D E

vendor standpoint) for different areas. In addition to computing centers providing services for the national scientific community, several mini- and microcomputers from different manufacturers are used for special purposes within CNR Institutes. Networking - The ever growing and diversifying demands from the field of research, the scarity of professional staff, the limitations of financial resources and the cost of software and hardware make it difficult for a single computer center to provide the extensive range of facilities required by the different fields of research. The interworking of different computers through a public data network allows the integration of facilities offered by the individual computing centers, with a consequent qualitative and quantitative enlargement of the overall computing facilities which would otherwise be impossible. The resulting computer networks will also be used as a basic communications tool for providing an information exchange system to support national projects. Interconnection of this computer network with other national and international (e.g. ARPANET, CSNET, EARN) networks is also forecast. In addition a new technical factor is appearing in the form of Local Area Networks (LANs) in various CNR Institutes with the result that networking should progress in the direction of interconnecting these LANs, rather than individual computers.

Right from 1979, CNR has been experimenting on the networking part of the above mentioned policy by using RPCNET: a packet switching distributed computer network [1] developed in the 1970s by C N U C E in collaboration with other scientific partners. However, RPCNET, which was designed and implemented in the first half of the 1970, was not adequate to implement fully the policy previously sketched, because of two big constraints which cannot be released in an "evolutionary" manner, but rather by a completely different approach: the homogeneity of the R P C N E T implementation (only the V M / 3 7 0 implementation is currently running) does not allow an integrated network of computers from different manufacturers; - The R P C N E T protocols do not comply with -

the new emerging standard protocols within ISO. In order to get rid of these limitations without losing the experience gained in designing, implementing and managing RPCNET, in the first half of 1982 CNR started a project called OSIRIDE (Open Systems Interconnection su Rete Italiane Dati Eterogenea - OSI on Heterogeneous Italian Data Network) which was conceived at C N U C E by a team of people from now on referred to as the " O S I R I D E team".

2. OSIRIDE:

Objectives

and Choices

OSIRIDE is mainly aimed at offering a uniform accessible set of communications and information services for unsophisticated users who want to cooperate in the framework of national (and possibly international) research programs. To achieve that, the following choices were made in the framework of O S I R I D E / I : Adoption of the O S I / R M . - The service and protocol choices made for layers 1 to 5 are described in detail in other papers ([2] and [3], for instance). A summary follows: • Network Layer A connection-oriented type of service based on ITAPAC (the Italian Public X.25 Network) was selected. • Transport Layer Class 2 Protocol • Session Layer BSS Subset - Within the Application Layer the File Transfer Application was selected. - Design of a Management System for managing and coordinating the complexity and sophistication of the overall OSIRIDE system to allow political, administrative and technical decisions. Operational tools will be needed to appraise the usage and performance of OSIRIDE. -

3. OSIRIDE

File Transfer

In the already mentioned papers [2], [3] the choice for the ECMA-85 File Transfer protocol was motivated by the following reasons: - No ISO standard protocol was defined at the

F. Caneschi et aL / OSIRIDE

time the O S I R I D E project started (June 1982). At that time the ECMA-85 standard had already been implemented by some manufacturers. - The next-to-come ISO standard would probably not have differed significantly from the ECMA-85 standard. The feeling of the O S I R I D E project team was that converting an ECMA-85 implementation to an ISO implemetation would not cost too much.

4. O S I R I D E

361 MHS

-

Following this philosophy, formal specs were produced, which not only featured a Pascal-like description of the ECMA-85 protocol, but also described in a similar way the user interface needed to perform a file transfer. In addition to that, a number of studies were done for the mapping of the ECMA-85 Virtual File structure into the structure of some real file systems [4-7]. As it often happens, the definition of the OSI F T A M evolved at a greater speed than that of i m p l e m e n t a t i o n within O S I R I D E 1, so the O S I R I D E team had to verify the assumption that not much effort was needed to move to OSI formal specs. As a conclusion, the O S I R I D E choices for what F T A M is concerned are: - Only the File Transfer part was selected. - The supported file structures are: 1. Unstructured 2. Flat - The Reliable File Service was selected. The interested reader can find more technical information in [8]. When one wants to implement the OSI FTAM, the Presentation aspects must be taken into account. This is not the case, for instance, for the ECMA-85 protocol, where only a few Presentation functions were supposed as existing over the Session Layer, and were described by the ECMA-84 D a t a Presentation Protocol. As a matter of fact the presentation aspects are the most valuable added work to be done when passing to OSI FTAM, mainly because almost all other existing protocols do not care of the Presentation Layer. or adopt ad-hoc solutions. 1 It is worth reminding here that the implementation of O S l R I D E is not performed by CNR, but either by manufacturers, or by specialized software houses. This major OSIRIDE requirement led us to pace with the imdustrial implementation times, which are rather different from those related to a research environment.

By the end of 1983, when O S I R I D E activity was well under way, the O S I R I D E team decided to look into the X.400 series of C C I T T Recommendations dealing with the definition of a standard Message Handling System (MHS). After a period of analysis and discussions, due to the C N R user needs and the amount of manpower available, the O S I R I D E team decided to concentrate its own efforts on the following components: the User Service, the Message Transfer Service and the Directory Service. While the first two components are specified respectively in Recommendations X.420 and X.411 the third one is currently under consideration by C C I T T (Study Period 1985-88). On the other hand, the Teletex gateway and protocol P3 were not included in the O S I R I D E initial program of work on MHS. The M H S protocol structure is shown in the left-hand part of fig. 1, whilst the right-hand part represents the initial O S I R I D E protocol structure. When we were about to start the definition of the formal specs for T.62, P1 and P2 we learnt that a system (EAN) capable of meeting the O S I R I D E requirements on M H S was already developped in a number of mainframes and operating systems by the University of British Columbia (Vancouver, Canada). The V A X / V M S version of it was then adopted and is currently under test on two O S I R I D E Pilot Centers (i.e. IASI, a C N R Institute and ISPT, a PTT Institute) both located in Rome. The IBM version of EAN

User Agent(P2) FTAM MTA

(Pl)

BAS Session

BSS Session

Class 0 Transport

Class 2 Transport

X.25

Fig. 1. Protocol layering.

362

F. Caneschi et aL / OSIRIDE

running under V M / S P will be adopted for O S I R I D E as soon as it is available. As is clear from fig. 1, the two "protocols piles" will initially run separately. Their integration will be faced by the O S I R I D E team in the future.

5. OSIRIDE Management

As no DP or DIS were (and still are) available in this area, the O S I R I D E project team had to design an architecture and an associated set of services and protocols to fill up this gap [9]. In terms of capabilities, the O S I R I D E management provides for: 1. Alarm Treatment - to signal and solve fault conditions. 2. Data Collection - to record End-System traffic in order to determine the use of the network resources and possible overload or bottleneck. 3. Software Distribution - to mantain network software, i.e. distribute new versions, coordinate their activation etc. 4. Report Generation and Presentation - to generate periodically any required set of reports and distribute them to the appropriate personnel. 5. Transparent Transfer Command - to transfer a command, issued by an O S I R I D E operator, transparently to a remote End-System according to the syntax and semantics of the related End-System.

turers will support the O S I R I D E choices in their future products at the Transport and Session Layers levels. As far as F T A M is concerned, the elaboration of the various choices is very well advanced. In fact, the O S I R I D E team has recently issued the O S I R I D E requirements on F T A M on which DEC, Honeywell, IBM and Olivetti seem to converge. All the manufacturers supporting O S I R I D E have officially set up within their organizations a group of people for the purpose of cooperating constantly with the O S I R I D E team. In addition to that, C N R selected a number of Pilot Centers 2 on which the O S I R I D E software will be tested. To avoid confusion, the O S I R I D E team decided to select only two Pilot Centers for each manufacturer with the intent of increasing that number as soon as the software is very well tested. 6.2. Who is doing

The implementation phase ( O S I R I D E / I I ) is currently being carried out by DEC, Honeywell, IBM and Olivetti as well as by a software house (TECSIEL) for the development of specific parts. 6. 3. Who will be doing

O S I R I D E software tests will start initially between two mainframes of the same manufacturer and then proceed to mainframes (already tested) of others. The O S I R I D E team will cooperate with maufacturers during the test phase on the O S I R I D E tested made up of Pilot Centers.

6. Who Was, Is and Will Be Doing What in OSIRIDE 7. OSIRIDE Implementation: State of the Art 6.1. Who Was Doing

As previously mentioned, the O S I R I D E choices were performed by the O S I R I D E team in the framework of O S I R I D E / I . Formal specifications of all the protocols previously outlined were produced by the O S I R I D E team in collaboration with Olivetti and Italsiel during the O S I R I D E / I project phase. In addition to that, a large number of bilateral meetings with DEC, Honeywell and IBM were held in order to keep them constantly informed about the O S I R I D E requirements and choices. The most important outcome of this approach is that all the above-mentioned manufac-

Due to different enterprise policies, the various manufacturers, in addition to the O S I R I D E choices, implemented other sets of classes, functional units and options. In the following sections, the implementation choices made for each system/manufacturer are described. A complete representation is sketched in fig. 2.

2 That is computing centers providing a service for the Italian scientific community.

F. Caneschi et al. / O S I R I D E C I.I

C 1.0

C 12

CI.4

C I.$

?-q

I--I

DEC Honeywell

I--1 I--1

IBM

F-q

Olivetti

OSIRIDE

Transport

363

package for the VM/SP4 operating system will be available before the end of 1985. The Transport protocol classes are 0 and 2, with all options, while the Session layer features the BSS subset, plus the Exceptions fuctional unit. For the purpose of testing the VM/SP4 implementation, CNUCE has and ESP (Early Support Program) with IBM, by means of which the operating environment has been made available some months before the official release. This will allow us to be ready for the initial tests of IBM OSI products by the end of this year.

DEC

B 5 5

@ ~

BAS

Honeywell

7.4. Olivetti

IBM

An implementation is already available and tested (within the manufacturer) for M40 and M60 systems, with a Transport protocol classes 2 and 3, and a BSS Session, plus the Exceptions functional unit. The implementation of Transport protocol classes 0 and 4, and BAS session subset is under way.

Olivetti

Fig. 2. Implementation cross references.

7.1. D E C

8. Operational Plan

The OSIRIDE software is provided on VAX systems running the VMS operating system. Transport protocol Class 4 is already available while classes 0 and 2 are under development and will be available by the end of this year. BSS Session is under development and will be available in spring next year.

The IBM (CNUCE/Pisa and CUC-PA/ Palermo) and DEC (IASI/Rome and ISPT/ Rome) Pilot Centers have already been connected to ITAPAC. The EAN software is currently under test on the DEC Pilot Centers. IBM tests on the Transport and Session protocols will start late this year, while for DEC and Honeywell they are scheduled for early next year. Hopefully before the end of 1985 the first cross testings will start between IBM and Olivetti computers. The others will follow later according to the progress of "homogeneous" testings. FTAM implementation is foreseen on each manufacturer by the end of 1986; as a consequence of that, an experimental heterogeneous file transfer service is envisaged for early 1987.

7.2. Honeywell

OSI products are provided on the DPS-6 and the DPS-8 systems. For the DPS-6, the Transport protocol classes 2 and 4 have already been implemented, while the BSS Session will be available at the beginning of 1986. The DPS-8 implementation features only the Class 2 Transport protocol, and, as for the previous system, the BSS Session will be available at the beginning of 1986. 7.3. I B M

An implementation, up to layer 5, is already available for the MVS operating system. A new

9.~eFu~e As the OSIRIDE project development is well under way the next step the OSIRIDE team is determined to pursue is in the direction of investigating the applicability of the OSI/RM for carrying out distributed applications running on

364

F. Caneschi et al. / O S I R I D E

computing systems made up of a cluster of PCs and general purpose machines loosely coupled with a high speed LAN. In the proposed system some PCs are allocated individually to users: in this case, a PC plays the role of a client. Other PCs are assigned statically to individual functions, such as printing and filing. In this case, a PC plays the role of a server. From this, it comes the name of the proposed extension of the OSIRIDE project, i.e. O S I R I D E / C S A . The basic assumption on which O S I R I D E / C S A relies is that the first six lower layers of the O S I / R M (by operating a sensible choice of services, protocols and options throughout the various layers) are adequate for moving data units between end-systems of a computing system of the envisaged system. The proof of that can be regarded as a fundamental objective per se of the O S I R I D E / C S A project. However, the design and implementation of sophisticated applications running in this environment 3 is also foreseen: this is on one hand another research aspect, and on the other hand, the way to prove our assertions.

[2]

[3]

[4]

[5]

[6]

[7]

[8] [9]

References [1] F. Caneschi, L. Lenzini and C. Menchi, "Status and evolution of the RPCNET network in an operational environ-

3 Which can thus be considered as a developing environment for OSI distributed applications.

ment", Proceedings of ICCC82, (North-Holland, Amsterdam, pp. 601-606. F. Caneschi, E. Gregori, L. Lenzini and E. Zucchelli, "Implementing the OSI standards: the OSIRIDE project", Proceedings of the First African Conference on Computer Communications, Tunis, May 1984. F. Caneschi, E. Gregori, L. Lenzini, C. Menchi and E. Zucchelli, "OSIRIDE: The Italian Answer to the OSI Reference Model", Proceedings of the Seventh International Conference on Computer Communication, Sydney, October 30-November 2, 1984, pp. 760-766. C. Bottaini and M. Fulgentini, "Ipotesi di struttura Interim-OSI elaboratori IBM per l'interconnessione in rete X.25 di elaboratori eterogenei", OSIRIDE internal document, Pisa, September 1983. DIGITAL Italy, "Architectures for implementing OSIRIDE", OSIRIDE internal document, Pisa, September 1983. S. Clivio and U. Valente, "Analisi delle problematiche relative al collegamento di calcolatori CDC con il progetto di rete OSIRIDE", OSIRIDE internal document, Pisa, November 1983. G. Bertocchi, L. Longhi, A. Pettinelli, P. Pezzuto, F. Proietti, "Integrazione architettonica DCA e progetto OSIRIDE", OSIRIDE internal document, Pisa, October 1983. F. Caneschi: "The OSIRIDE FTAM", internal OSIRIDE report, July 1985. C. Bolzoni, P. Bucciareili, E. Gregori, L. Lenzini, C. Menchi and E. Ruzza, "The design of the OSIRIDE Management functions", OSIRIDE Working document.