8
Progress towards open system standards Standards for open system working have attracted attention for some time. They are becoming increasingly important for a number of reasons: Such standards ease the interconnec- tion of equipment of differing ranges, origins and types by providing a stan- dard means for interworking between such subsystems. The changing balance between staff and equipment costs is favouring the networking of datasets that have been keyed, rather than rekeying datasets when required at a second or further location. Open system stan- dards will enable sets of digital data to be networked without restriction. Considerably eased forward com- patibility will be provided by open system standards. They will allow some systems components to be changed or added without distribu- ting the remainder of the system. For example, intelligent terminals may be added or changed with only marginal alterations to the main- frame(s) to which they are connec- ted when new services are to be added, or the user wishes to exploit additional facilities provided within the mainframe. Slight modification to the actual datasets (packets or blocks) will be easily accommodated, as it seem likely that such formats will be based on the well-established self-defining field concept, in which a signposting header block indicates the presence of following blocks, all aligned with standards for layout and packing. Changes in the trans- ferred dataset formats thus range only minor changes to the self-de- fining header block. They are the key to a number of future applications of computers, as future maior applications may well involve the unrestricted or minimally restricted interconnection of large numbers of subsystems distributed internationally. Examples include electronic funds transfer, where se- curity is a key factor, and electronic mail, where access to all necessary addresses is obviously vital. Other examples include systems for hand- ling international trading and trans- portation documents such as way bills and customs documentation. A sequel to the above will be an in- crease in the size of the marketplace for computing systems - clearly of benefit and interest to the system manufacture and service industry. Open system standards will increase the number of feasible systems as outlined above, and also possibly de- crease the cost of many implementa- tions, leading to a natural growth in the number of technically possible and cost-effective systems. Open system standards will allow all interested users using proprietary equipment or common software standards to share implementation costs, as only one implementation of each key component will be needed. This should decrease the cost per implementation, in spite of the in- creased scope and complexity of the systems so generated, because they are generally applicable, rather than restricted to particular applications. Interest in and support for many of these principles was clear at the SC16 (subcommittee of ISO committee TC97) meeting held in Washington DC, February 28-March 2,t1"978). Users were well represented within the various national delegations, as were manufac- turers, several of whom had representa- tives at the meeting, both within the national and liaison delegations, includ- ing ICL, Burroughs, IBM, Digital Equip- ment, NCR and Univac. Their presence was important, as their cooperation is vital if implementation in this import- ant area is to be rapid and effective. FOCUSING ISO's ATTENTION ON OPEN SYSTEM STANDARDS During 1975, it became clear that stan- dards for data transmission that were capable of satisfying forseen require- ments for the next decade or so would soon be agreed. These standards are based on the X.21 series of interfaces for digital transmission systems (the V.24 series for analogue systems are likely to be phased out), the HDLC standard, to which the CCITT X.25 frame structure and procedure standard (LAP-B) was aligned early in 1977, and when packet-switching systems are used, the relevant part of the X.25 standard. Packet-switching systems allow the interconnection of a wide range of sub- systems (terminals and processors) of widely differing types and characteris- tics, as packets can be transferred to and from the corrected devices at various bit rates on 'demand'. They offer un- restricted interconnection of all devices capable of working to the same inter- face, with no restriction on interdevice switching or device transfer speeds. This situation led to careful consi- deration of the nature and management of the data transfers represented within such packets, or equivalent widely inter- linked circuit-switched lines working to the same HDLC standard, although the latter are necessarily restricted by the need to match data device transfer speeds. An initial examination of the problem by working group (WG) 5 of BSI Committee DPS/5 soon showed that there could be problems in repre- senting and managing widely differing types of data transfer in this one flexi- ble standard while accommodating pro- prietary or user-dependent information within appropriate substructures. The early work performed by that group has been described fully 1. A number of areas were identified where such standards are needed, including com- mand and user task representation, task setup and transfer management, and the development of an interface to the transmission system, otherwise termed transport service, independent of the type of service used. This is required to eliminate the need to change outputs of the upper levels of protocol (so-called higher-level) when a different transmis- sion service is used. The need for a service-independent transport station interface was thus defined. Figure 1 shows the model or representation of requirements as developed by March 1977. Consequently, the case for establish- ing a new ISO subcommittee was pre- sented to TC97, the ISO computing/ 210 0140-3664/78/0104-0210502.00 © 1978 IPC Business Press computer communications

Progress towards open system standards

  • View
    214

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Progress towards open system standards

Progress towards open system standards

Standards for open system working have attracted attention for some time. They are becoming increasingly important for a number of reasons:

• Such standards ease the interconnec- tion of equipment of differing ranges, origins and types by providing a stan- dard means for interworking between such subsystems.

• The changing balance between staff and equipment costs is favouring the networking of datasets that have been keyed, rather than rekeying datasets when required at a second or further location. Open system stan- dards will enable sets of digital data to be networked without restriction.

• Considerably eased forward com- patibility will be provided by open system standards. They will allow some systems components to be changed or added without distribu- ting the remainder of the system. For example, intelligent terminals may be added or changed with only marginal alterations to the main- frame(s) to which they are connec- ted when new services are to be added, or the user wishes to exploit additional facilities provided within the mainframe. Slight modification to the actual datasets (packets or blocks) will be easily accommodated, as it seem likely that such formats will be based on the well-established self-defining field concept, in which a signposting header block indicates the presence of following blocks, all aligned with standards for layout and packing. Changes in the trans- ferred dataset formats thus range only minor changes to the self-de- fining header block.

• They are the key to a number of future applications of computers, as future maior applications may well involve the unrestricted or minimally restricted interconnection of large numbers of subsystems distributed internationally. Examples include electronic funds transfer, where se- curity is a key factor, and electronic mail, where access to all necessary

addresses is obviously vital. Other examples include systems for hand- ling international trading and trans- portation documents such as way bills and customs documentation. A sequel to the above will be an in- crease in the size of the marketplace for computing systems - clearly of benefit and interest to the system manufacture and service industry. Open system standards will increase the number of feasible systems as outlined above, and also possibly de- crease the cost of many implementa- tions, leading to a natural growth in the number of technically possible and cost-effective systems. Open system standards will allow all interested users using proprietary equipment or common software standards to share implementation costs, as only one implementation of each key component will be needed. This should decrease the cost per implementation, in spite of the in- creased scope and complexity of the systems so generated, because they are generally applicable, rather than restricted to particular applications.

Interest in and support for many of these principles was clear at the SC16 (subcommittee of ISO committee TC97) meeting held in Washington DC, February 28-March 2,t1"978). Users were well represented within the various national delegations, as were manufac- turers, several of whom had representa- tives at the meeting, both within the national and liaison delegations, includ- ing ICL, Burroughs, IBM, Digital Equip- ment, NCR and Univac. Their presence was important, as their cooperation is vital if implementation in this import- ant area is to be rapid and effective.

FOCUSING ISO's ATTENTION ON OPEN SYSTEM STANDARDS

During 1975, it became clear that stan- dards for data transmission that were capable of satisfying forseen require- ments for the next decade or so would

soon be agreed. These standards are based on the X.21 series of interfaces for digital transmission systems (the V.24 series for analogue systems are likely to be phased out), the HDLC standard, to which the CCITT X.25 frame structure and procedure standard (LAP-B) was aligned early in 1977, and when packet-switching systems are used, the relevant part of the X.25 standard.

Packet-switching systems allow the interconnection of a wide range of sub- systems (terminals and processors) of widely differing types and characteris- tics, as packets can be transferred to and from the corrected devices at various bit rates on 'demand'. They offer un- restricted interconnection of all devices capable of working to the same inter- face, with no restriction on interdevice switching or device transfer speeds.

This situation led to careful consi- deration of the nature and management of the data transfers represented within such packets, or equivalent widely inter- linked circuit-switched lines working to the same HDLC standard, although the latter are necessarily restricted by the need to match data device transfer speeds. An initial examination of the problem by working group (WG) 5 of BSI Committee DPS/5 soon showed that there could be problems in repre- senting and managing widely differing types of data transfer in this one flexi- ble standard while accommodating pro- prietary or user-dependent information within appropriate substructures. The early work performed by that group has been described fully 1. A number of areas were identified where such standards are needed, including com- mand and user task representation, task setup and transfer management, and the development of an interface to the transmission system, otherwise termed transport service, independent of the type of service used. This is required to eliminate the need to change outputs of the upper levels of protocol (so-called higher-level) when a different transmis- sion service is used. The need for a service-independent transport station interface was thus defined. Figure 1 shows the model or representation of requirements as developed by March 1977.

Consequently, the case for establish- ing a new ISO subcommittee was pre- sented to TC97, the ISO computing/

210 0140-3664/78/0104-0210502.00 © 1978 I PC Business Press computer communications

Page 2: Progress towards open system standards

BSI

Executive bodies Nonexecutive bodies

IS0/TC97 IEC CCITT CEPT IFIP BCS ECMA BETA

Prioriw level ~ Terminology ~--- TCI SG 1 TC 1 DPS/16 SC 1

DPS/11 SC 15 GP 5 Comrpands DPS/5WG5 WG JCL TC 1 / c~sG

Task Data I Files and their attributes ~l and its I structure including DPS13 TC 9 Cass, and I structure I programming languages (Pl.s) SC 5 action I and media headers TC 15 WP control ~ ] DPS11 SC 15

I I (Files) TC 17 I DPS9 SC 14 I (Data) SO6 TC 19

~ - " DPS5/WG5

Varying levels Real ~ Interactive Remote O ine job of prioriW (4?) time ~ ~ entry !

I I I

Type, functional checks and feasibility checks

Dedicated next highest Network management level of priority for - flow control DPS5PAtG 1 SC 6/WG 1 SG Vll TC 6 management messages - circuit switched/datagram/ DPS5/WG2 SC 6/WG 2 WG 6 1

virtual call

Routing and scheduling using DPS5/WG2 Dedicated highest level private/switched networks of priority for management control information DPS5/WG 1

Link control protocols . j DPS5/WG2

Engineering level protocols l - DPS5/WG2 DPS5/WG3

Communications systems control hardware J DPS5/WG3 Private networks PSN s l DPS5/WG 1 Data communication network configuration DPS5/WG2

' DPS5/WG3

SC 6/WG 2

TC 9

TC 9

SG VII TC 9 Sp. A

SG VII TC 9 Sp. A

SG VII TC 9

Figure 1. Protocol structure and organizations interested and involved (produced by WG 5 of BSI Committee DPS/5 in Janu- ary 1977) (a considerable number of contributions, including the UK's, extended and built upon this early layered model) (PI.s -- programming languages)

data-processing committee, at its meet- task of SC16 is to provide an environ- considerable attention was given to ing in Sydney in March 1977, and it ment that exploits the data transmis- development of a composite model was ultimately narrowly approved. Its sion standards that facilitate the inter- and the interchange of ideas previously assigned scope and programme of work connection of subsystems with no or developed, after initial discussion and reflect the importance of liaison with few restrictions and that also provide consideration of the scope and pro- all interested parties and the active par- means for the unrestricted transfer of gramme of work. ticipation of several ISO committees messages, data and executable tasks be- and other bodies. Representatives of tween computing systems via dial-up C O N T R I B U T I O N S TO T H E one such ISO committee, TC97/SC6 or permanent communications links, W A S H I N G T O N M E E T I N G data transmission, were present at the or possibly offline links. The alignment first SC16 (Washington) meeting, as of such standards is very desirable if Scope and programme of work of were representatives of the CCITT. not vital. SC16 Its terms of reference also reflect A basic model for such standards the need to incorporate suitable stan- identifying the components (so-called The scope and programme of work of dards for open system working develo- levels or layers in the structure outlined SC16, as presently drafted, instructs pad elsewhere within ISO and other in Figure 1) is fundamental to the pro- SC16 to investigate models for open standards bodies. For example, file duction of such standards, and it was systems working, and identify standards labelling standards for the representa- given a high priority in the scope and developed elsewhere that can be incor- tion of data elements and projected stan- programme of work. Such a model porated into such standards. However, dards for the transfer of graphic display represents an overview of, and structure it specifically prevents SC16 from actu- files and possible numerical control for, the various elements of open sys- ally developing standards until instruc- (NC) file should be incorporated when tam standards, which must together ted to do so by its parent committee, appropriate, provide the facilities required. ISO TC97. A contribution by the UK

It is generally agreed that the main During the first meeting of SC16, suggested that this should be interpre-

vol 1 no 4 august 1978 211

Page 3: Progress towards open system standards

User A User B

. . . . . User access

User access layer User access protocol (UAP) (UAL) ~ ~ Transport services

Transport protocol (TP) __ Telecommunication

T a sport layer ( ~ces

Telecommunication subsystem

Translation User A ~ l l

U A P

UA..._L . . . . . .

TL T P ~ _ _

User B

E,g. Start/stop equipment

Telecommunication subsystem Communication between translation function and terminal equipment

Virtual network interface Equipment of User A Translation Equipment of User B

Figure 2. Conceptual way of progressively interconnecting existing equipment and migrating towards 'universal' protocols (presented by Canada)

ted broadly, while still satisfying the instructions of TC97. A Japanese con- tribution went further, and recommen- ded extension of the scope to include the words 'standardization of higher- level protocols'. While there was con- siderable sympathy with the Japanese view, it was felt that it would be un- wise to try to change the scope and programme of work at this time, as it would necessitate the approval of the parent committee and could lead to delays at a critical stage - it is vital to make progress while there is consider- able enthusiasm and interest in SC16's work.

The work of a number of active na- tional and liaison bodies was described, in all cases emphasizing the model for open systems architecture which must be defined before requirements can be clearly identified and associated with the model structure.

Canada

The first of two contributions from Canada presented a well structured ap- proach to a number of issues that had not previously been identified. These included 'broadcast operations', i.e. simultaneous one-way or two-way com- munication between three or more users, and multiuser interactive mode capable of supporting group interaction. The need to resolve contentions between users requesting control in the latter case, and also in the simple two-party case, was also highlighted. This contri- bution also clearly separated informa- tion flow, concerned with the transfer of data, and supervisory functions, concerned with the management rather than the operational aspects of such transfers.

The second contribution from Cana- da addressed an equally important topic - that of progressive migration, or the bridging of existing system com- ponents and equipment. After it was indicated that the virtual terminal ap- proach can be used to resolve differen- ces between differing terminal details such as codes used, line lengths, and mechanical control, it was shown that there is no need for translation within the network, providing that each ter- minal and its software have an inter- face to a common virtual terminal pro- tocol (V-I-P). Any requested VTP func- tions and services not implemented within a particular terminal are conver- ted into functions that are available (See Figure 2).

The conslusion was that the VTP concept becomes redundant when stan- dard terminal access procedures are available. It was suggested that the same approach can be used to allow users to interconnect to virtual net- work protocols (author's term) which would similarly become redundant when universal standards are fully implemented.

France

Two speakers from France commented on the terms of reference of SC16, and recommended that it be allocated res- ponsibility for defining an overall refer- ence architecture for standards for open systems interconnection, which should build upon the earlier work undertaken within ISO's data communi- cations subcommittee (project 17 of SC6).

The second French contribution outlined the development of the earlier French model for communications

systems, and its extension to cover pro- cess-to-process communications. This model proposes an end-to-end trans- port control protocol for message trans- fer control, and numerically refers to the transport station interface as level 0. Communication levels thus become -1, - 2 etc., (see Figure 3). Functions at the lower level can be chained, that is, can pass through a sequence of levels such as 0, -1, -2, -1 ,0 , -1 , - 2 etc. The output of such a chain is regarded as a single transfer to lower levels by the higher levels, that is those above 0.

Japan

The Japanese delegation expressed anxieties over the terms of reference

2

1

/ / / / / / / / / / ,

Process-to-process protocol (e g a VTP)

End-to-end transport control protocol (the alternative USA term is Message Control)

~Transpor t / station interface {

X,25 level 3

HDLC t

Physical (line) level

1

r 1 1 / 1 1 / 1 1 1 1

Figure 3. French model for systems architecture 0(.25 level 3 used as an example of a possible packet or envelope level)

212 computer communications

Page 4: Progress towards open system standards

Table 1. Functions of the levels within the Japanese model

Level Examples of Level name identified Functions standards Field

User Level 5 Functions defined by users

Information processing field

Functional Level 4 Examples of function: • setting up and clear-

ing of a logical path connecting users, and message transfer

• Virtual terminal protocol

• Remote job entry • File transfer • Network manage-

ment (configuration management, opera- tion management, failure management etc.)

Communica- tion pro- cessing field

Transport Level 3 Transparent data trans- • ISOfrC fer functions between 97/SC6 pro- two network nodes ject 24 (connected in general • CCITT X.25 by two or more links) packet level

Datalin k Level 2 Communication pro- • HDLC Transfer tocols between adja- • CCITT X.25 field cent network nodes LAP-B connected by a link

Physical Level 1 Electrical and physi- • CCI'I-I" V.24 cal connectingcondi- • CCITT X.21 tions for communica- tions media

of SC16, already outlined above, and recommended that they be changed. After considerable discussion, they agreed that an interpretation of those already assigned would be acceptable for the time being, so as not to unduly delay progress. Standardization in this area is proceeding rapidly in Japan, and the basic elements of the Data Communi- cations Network Architecture (DCNA) project were outlined. This is a cooper- ative development project between the Nippon Telegraph & Telephone Co. and four computer manufacturers: Nippon Electric Co. Ltd., Hitachi Ltd., Fujitsu Ltd. and Oki Electric Industrial Co. Ltd. Four examples of heterogeneous (mixed-supplier plus PTT) computer

networks already working in Japan were noted.

The model presented by Japan broadly followed the early UK model shown in Figure 1, with some develop- ments. Service functions, such as logi- cal-path establishment/clearing, virtual terminal protocols, remote-job-entry protocols, file-transfer functions etc., are separated into a lower layer termed the functional level (see Table 1).

A later crosscomparison of this model with others presented to the meeting showed considerable similarity, the main difference being the separation of certain functions into a separate layer rather than a separate sublayer, as in most other cases.

UK

The UK has identified the importance of open system working over the last three years ~. UK ideas have had limited circulation, and its presentation, by Andrew Chandler of the CAD Centre, was thus limited to key points and re- cent extensions, particularly the develop ment of the concepts of indicating en- tities within the model layers. Its key features, a top-down approach look- ing inwards and downwards to the com- munications subsystems from the user command and task representation level, through a task management level fol- lowed by a service-independent trans- port station interface and the transport layers, were highlighted.

Within any upper layer, the need to represent the local state, the remote state of the corresponding entity and the status of the communication link were outlined. The need to reflect such requirements within the crosslayer (peer-layer) protocols was emphasized. Interentity communication may be necessary within a conceptual layer; for example, remote job entry and file- transfer junction both require a bulk- data-transfer function as one active ele- ment when they are actioned. These and related matters were explored later by the ad hoc group, as outlined in the section on provisional model development.

USA

The most comprehensive presentation was that of the USA, which lasted about four hours. Dick des Jardins of NASA presented the US view of the various elements within the six-layer model developed in the USA (see Fig- ure 4). The early part of the presenta- tion contained an interesting definition of open systems standards as those which provide, as an ultimate goal, means

'To make all processes in the world addressable to one another such that they can exchange information where such exchange appears useful, independent of their location or physical characteristics'.

The lower three layers correspond to previous well established thinking, the major difference being that there seems

vol I no 4 august 1978 213

Page 5: Progress towards open system standards

to be much less awareness of the X.25 link/packet-level interface and its impli- cations within the USA. Later, a most useful and constructive exchange of ideas, concepts and information related to these levels occured during an ad hoc working group meeting.

The three upper levels, concerned with task representation and use of the transport service, presented a radically different approach. The three upper layers are, starting with the lowest first:

Session control

This level provides for the reliable trans- fer of datasets passed to it by the two levels above, and for the coordination of transfers. It uses features such as mailboxes (buffers) in the linked sub- system, which form part of a work- station providing a user interface plus processing capability. A session node corresponds to a local combination of one or more transport service inter- faces plus one or more workstations and/or mailboxes.

Presentation control

This level is concerned with adapting the actual data input/output ports of a process to the characteristics of the session control interface, including transformation of commands and data to accommodate the needs of widely different terminal types (such as that performed by the differing implementa- tions of a V'FP). The US proposed that it include FORTRAN and COBOL file interfaces, and such system functions as information-code conversion (e.g. ASCII to EBCDIC), encrypting/decryp- ring, data compacting/expanding (pack- ing), and transformations to/from par- ticular display file formats.

Process-to-process communication

This level, which can alternatively be termed the application level, is specifi- cally concerned with providing a vehicle for applications and system activities that are user-dependent. No generali- zation can be made, although it should be possible to accommodate or enve- lope particular applications or industry standards within the level, such as those under development by banks, for inter-

national trade and freighting, order entry protocols, distributed database access protocols, and source code in a standard programming language. It corresponds closely to the UK's earlier task representation level.

This approach stimulated consider- able discussion, culminating in the es- tablishment of the three ad hoc groups outlined below.

Other national bodies

Other statements were made by the representatives of the FDR, Italy, the Netherlands, Sweden and Switzerland. In some cases, work is only just begin- ning, while in others (e.g. Sweden) it is concentrating on areas such as interna- tional trade information systems.

CCITT

The successful method of operation of the CCITT was summarized by V C MacDonald of Canada. The CCITT has distributed a questionnaire asking its operating members if they intend to use the X-Series Recommendations, and has sought information on the steps and recommendations needed to make the agreed services possible. These are likely to involve VTPs. A CCITT contri- bution, in the form of an extract from one of its documents, clearly indicates

its interest in mode-independent end-to. end protocols, i.e. the level just below the transport station interface.

ECMA

E CMA tables two documents. The first examined the philosophy of open systems working and basic needs. It states that such standardization should improve cost effectiveness in two ways, as

competition will be stronger, standardization should yield econo- mies because of the manufacture of greatly increased volumes of stan- dard communications components.

The second paper supported this with a complementary discussion defining terms more clearly.

IFIP

IFIP General Note 96.1, now being circulated widely, was presented. It is a proposal for an internetwork end-to- end protocol, and it contains many ideas and principles in line with the contributions outlined above. It em- phasizes the transport protocol struc- ture and important transport service aspects such as path establishment, flow control and delivery confirmation, and deals with task fragmentation and reassembly before and after transfer.

Process • 6 6 IWer 1 Presentation 5 control

T PL

5 PC

4 SC

3 3 TNC

2 2 LC

PC

Information processing subsystem 2

Session control 4

Transport network control

Link control

Physical control ,:di k

I

Information processing Communications subsystem 1 switching

node

Figure 4. 6-layer model (prel~red by the USA)

Interested standardization organizations

ISO, ANSI, and application oriented bodies, e.g. ICA0

ISO, ANSI (especially coding and language committees)

ISO, ANSI

ISO, CCITT, ANSI

ISO, CCITT, ANSI, FIPS

ISO, CCITT, EIA. ANSI

214 computer communications

Page 6: Progress towards open system standards

ISO Committee 97/SC6 Data transmission

Ed Lohse, chairman of SC6, outlined the SC6 activities that overlap with SC16, and indicated that SC6 project 17 (system architecture) (rapporteur: H Zimmerman, France, later to become convenor of SC16 WG1 on models - a nomination that solved all liaison dif- ficulties) and project 24 (end-to-end protocols) (rapporteur: Bud Emmons of IBM) are of particular concern to SC16. He indicated his committee's support for the work of SC16, and invi- ted an SC16 representative to attend the SC6 meeting in May 1978.

DEVELOPMENT OF A PROVI- SIONAL MODEL

Following the above presentation of current work and thin king, an inter- active discussion based on a single-mat- rix-type diagram showed that consi- derable common features already exis- ted within the models presented. Three adhoc groups were established to ex- plore detailed points, concepts and principles. These provided a valuable opportunity for the interchange of ideas, and allowed international think- ing in these areas to be further aligned. Separate groups covered model con- cepts and development, transport ser- vices, and users of transport services, these being led respectively by H Zim- merman of IRIA (France), C Solomo- nides of NPL (UK) and R des Jardines of NASA (USA).

The first group was charged with the responsibility for examining overall architecture, including the structure

of the model, the cases for combining or separating control and data inter- faces, ways of formally defining and representing the model, and the ter- minology used to describe it. It con- firmed the unilateral interest in a layer- ed model already demonstrated by the preceding presentations, examined the combination or separation of control and data functions without reaching a preference for either, and defined a number of terms used to describe model features.

The second group discussed the transport service, its nature and func- tions, the number of layers required to represent it, and various interfaces within such a service. It concluded that an end-to-end protocol layer should be added to the three layers previously identified in accordance with the three X.25 levels, also identified in the US presentation above), and corres- pondingly proposed that the transport service be represented by four layers in the composite model under pre- paration.

The third group also discussed the number of layers needed to represent the levels using the transport service, and subsequently confirmed the US model, using three layers. Most of its discussions centred on the relative func- tions of such layers - such activities as commitment after a transfer, or, simply, confirmation of datasets recei- ved correctly and acceptably. Discus- sion within each group converged to- wards the identification of problem areas that need to be tackled as vital components of the present considera- tion of the nature of the standards re- quired, and ways of developing and implementing them. Consequently,

Layer number Function

7 Process control

6 Presentation control

5 Session control Transport station interface ~ ~.//,/~, ~ . / ' / / / / / / / / / / / / / / / / /

4 Transport end-to-end control

3 Network control

2 Link control

1 Physical control

Active communicating Active communicating subsystem subsystem

Conceptual communication between peer layers, P1, P2, etc. Layer number

P6

P5

- - P 3 - - L ~ - - P3 - - P2 - - P2

P1 - - P1

Network node (switching node)

Layers using the transport service

Layers providing the transport service

Figure 5. Key elements o f the outline model for open system working identified at the SC 16 meeting (layers up to and including the network control layer may be 'chained' as the data blocks pass through successive network nodes)

three corresponding ISO working groups were set up.

FEATURES OF THE PROVI- SIONAL MODEL

The models presented had much in common and all conformed to the concepts of layered architecture shown in Figure 1. Most conformed broadly to the actual layers shown, with a change of function and title, e.g. as in the USA model. Following the major part of the discussion of ad hoc group 1, H Zimmerman merged the various contributions into a composite provi- sional model, shown in simplified form in Figure 5. This clearly separates transport services and users of transport services by a service independent inter- face, the definition of which is critical if work is to proceed independently above and below it linked only by that interface. As mentioned earlier, work in the transport service area is well under way within the CCITT and ISO TC97/SC6 Data transmission.

For example, the process-control layer, the top layer, corresponds to the control of the execution of appli- cations and their attributes, including the control of application and system activities needed by the information processing function. These include the initiation, execution control, and ter- mination of tasks, and the correspond- ing assignment of hardware and soft- ware entities used. This layer must provide the capability to incorporate particular protocols for purposes such as funds transfer, electronic mail, air- line operation, order entry etc.

The presentation control, layer 6, separates a number of activities and functions previously bundled with appli- cation attributes in the UK, and inclu- des information transformation where needed, such as in the conversion of a VTP to that needed for a real terminal, information packing and un packing, encryption/decryption where needed, and the transformation of information into the process data units required by level 7.

Session control, layer 5, extends the basic user command functions identi- fied in the UK, and includes the basic commands, units that commit certain resources to certain tasks or user acti-

vol 1 no 4 august 1978 215

Page 7: Progress towards open system standards

vities, 'quarantining' units that isolate part or whole datasets until their vali- dity is confirmed, and the supervision of activities such as recovery, including handling checkpoints and transaction logs.

This level also includes a mailbox function allowing interuser communi- cation, either as a stand-alone activity, or in relation to task processing.

Agreement that the interface between those elements or layers concerned with data transfer or transport and those concerned with data management re- presentation (Figure 5) is critical was unanimous. This model was examined by the plenary meeting, and confirmed as a valuable step in the right direction. A number of problem areas that need to be examined and resolved were identi- fied and later passed to corresponding ISO working groups for action. For example, a finer definition of the term transport services, i.e. whether it should be applied to online links only, or to online links and fast offline links, was later assigned to ISO WG 1.

E S T A B L I S H M E N T OF ISO W O R K I N G GROUPS

The ad hoc discussion groups identi- fied a number of areas that need to be investigated further. Six areas of im- portance were identified, and corres- ponding projects established. They are:

• the definition of a model for an archi- tecture for standards for open sys- tem working,

• the development of formal notation for the representation of model elements,

• process-to-process (user-level) pro- tocols, i.e. those generally above the transport station interface,

• protocols for the exchange of struc- tured data (file transfer),

• virtual terminal protocols, • transport station operation and the

interface between layers above and below the upper transport station interface.

Apart from the second topic, these correspond to existing WGs of the UK committee, which is thus in a strong position to contribute.

ISO SC16 WGs with responsibility for progressing the above projects were established on the last day of the meet- ing. Because of the limited resources available for travel to remote meetings and the time taken, it was agreed to limit the number of ISO WGs to three. (This point was strongly supported by the Japanese, who are far from Europe and the USA, but highly active in the field).

The WGs were established, and their convenors are: WG I. Models and architectures for open system working, secretariat to AFNOR, France; convenor H Zimmerman, IRIA, Versailles, France; projects I and 2 above assigned; WG 2. Users of transport services; secretariat to BSl, UK; convenor Dr Alwyn Langsford of AERE, Harwell, UK; projects 3, 4 and 5 assigned; WG 3. Users of transport services and their upper interface; secretariat to ANSI, USA; convenor G White; pro- ject 6 assigned.

The UK convenor of WG2 thus has responsibility for progressing several crucial areas, particularly VTPs, where work must keep pace with work within and by the PTTs. This is coordinated via the CCITT, which links their tele- communications interests. Relevant work on file transfer is already well established within the British Post Of- rice EPSS high-level protocol group, and it will be input to ISO WG2 when appropriate.

F U T U R E PROGRESS

Resolutions

The resolutions proposed were all accep- ted on the last day of the meeting with little dissent. These include resolutions interpreting the scope and programme of work, defining liaison channels and their implementation, and establishing working groups. These resolutions were all passed unanimously.

Matters under consideration

Process4evel protocols

These are sometimes termed user or application level protocols. They are

being examined by several groups, in- cluding the model task activation work- ing group of the UK's DPS/20, and the architecture working group of DPS/20; both are also concerned with user com- mands and task representation. Bodies such as the UK's Board for the Simpli- fication of International Trade Proce- dures (SITPRO) are also interested in particular sectors of this area, and their collaboration with DPS/20 is already proving valuable. It is hoped that cor- responding international liaison and collaboration will soon occur.

Mapping problems

One of the features of any model in this area is that it must provide for one-to-many and many-to-one mapping, or transfers, between conceptual layers. For example, several application-orien- tated protocols within the process layer (level 7) need a single set of facilities provided by level 6 (although there may be several alternative sets, such as differing virtual terminal protocols, that can only be used one at a time within each liaison); then in turn using a common set of facilities provided by level 5 - session control. The opera- tion of mapping software performing data format conversions will need to be resolved.

Interlayer communications, and man- agement of information flow within upper levels

The flow of information and the se- quences of datasets being transported via a single communications channel have already been studied in the trans- portation area, and is known as flow control. However, it is not clear where the interface controlling the flow will be placed within the upper layers - in series or in parallel with the data interface. This needs further study.

Path establishment and availability indicators

The logical establishment of intersub- systems paths is an activity that must be carried out by all layers before a link or liaison can occur. However, the master layer responsible for controlling such a link has not been clearly identi-

216 computer communications

Page 8: Progress towards open system standards

fied, and nor has the handling of avail- ability tables, which clearly indicate the states of available transport service paths, and process to where links fre- quently occur. These also need to be studied further.

Report to parent committee TC97

SC16 is charged with reporting the pro- gress made and the feasibility of stan- dardization in the area to the next meet- ing of TC97 to be held in Madrid in November 1979. Every attempt will be made to produce a firm ISO SC16 model to be used as a basis for the first set of open system standards by March 1979. Correspondingly, meetings of all WGs have been scheduled for mid 1978 (J une/J uly) and two full meet- ings of SC16 for October 1978 and March/April 1979. Hopefully, the model will be confirmed by the latter meeting, and its development, defini-

tion and the scope for inclusion of exis- ting or projected standards or compo- nents also identified.

This is a tight schedule, but one which needs to be maintained if the proliferation of proprietary network architecture is to be avoided, and imple- mentation of the standards (which must be available) is to occur. A multitude of such proprietary architecture, not easily interconnectable or mappable onto the standard, could create con- siderable problems, and retard the growth of computer applications.

CONCLUSIONS

The author's personal conclusions are that this was a successful meeting that has raised considerable hopes for the future. Constructive and rapid progress should now be possible.

This paper is based on the author's personal impression of the meeting,

and it concentrates on progress made within the first SC16 meeting, rather than presenting the basic concepts in layman's terms, as a working party of the UK's Committee, DPS/20 WG5 has been established to develop ways of disseminating requirements, concepts and terms used to the general comput- ing community.

F Taylor* Systems Technology Consultants

Knutsford, UK

REFERENCES

1 Houldsworth, J 'Standards for open network operation' Comput. Commun. Vol 1 No 1 (February 1978) pp 5--12

* Leader of the UK delegation to the first ISO TC97/SC16 meeting in Washington DC

US National Bureau of Standards

Computer network interconnec- tion: problems and prospects (I W Cotton) (1977) (1~1.45) (SD 003-003-01757-4)

The current situation regarding the interconnection of computer networks, especially packet-switched networks (PSNs), is examined. The emphasis is on identifying the barriers to intercon- nection and on surveying approaches to a solution, rather than recommend- ing any single course of action.

Four major types of interconnec- tions are then: circuit-switched net- work to PSN, star network to PSN, simple terminal to PSN, and PSN to PSN. The major barriers to intercon- nection, both political/legal and techni- cal, are outlined. The report concludes with some comments on the prospects for overcoming these barriers.

A bibliography, glossary with list of abbreviations, and listing of existing data communications standards rele- vant to interconnection are included.

[ ]

A data base management approach to privacy act compliance (E Fong) (1977) (t~1.40) (SD 003-003-01787-6)

The US Privacy Act (PL 93-579) "provisions on personal record handling present new issues concerning the effective use of commercial database management systems by Federal agen- cies. The widespread use of such sys- tems in recordkeeping activities will have an impact on methods of adminis- tering compliance with the Privacy Act. The report proposes a technical approach to compliance with certain Privacy Act requirements through the

use of generalized database manage- ment systems. Requirements are trans- lated into a set of computer data file and procedures. These procedures, in- corporated at pivotal points of data- base software, can implement those Privacy Act compliance procedures amenable to automation. The use of DBMS appears to be a viable and tech- nologically feasible solution to the effective and efficient implementation of many Privacy Act provisions. [ ]

Audit and evaluation of computer security (Z G Ruthberg and R G McKenzie) (1978) (IN.00) (SD 003-003-01848-1 )

What controls are needed for a compu- ter security system? How can managers make sure the system is working properly?

Computer security audits are impor- tant management controls for prevent- ing and detecting fraud and errors in automatic data processing operations. Independent evaluations are used to

vol 1 no 4 august 1978 217