AU664256B2 - A network interface - Google Patents

Description

S664256 P/00/011 28/5/91 Regulation 3.2

AUSTRALIA

Patents Act 1990

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT rri~

~I

I

r.

Invention Title: A NETWORK INTERFACE

,U

ti U 4464 t I CiI, The following statement is a full description of this invention, including the best method of performing it known to us:- 2 This invention relates to a method for providing services corresponding to an application level communication protocol using services provided by a non- OSI network, and to a network using the same.

The ISO/OSI reference model for communication networks contemplates a seven levels layering of protocols: each level provides more and more sophisticated services. The highest level is the so-called application level and it is the one on which the various applications residing on systems, in general computers, connected with the network themselves, should be based.

In theory, should one desire to realise a network which allows the connection of completely different types of systems it would be necessary to provide, generally in SW or FW, layered network interfaces according to such reference model.

If such a proposal is acceptable, should one desire to connect in network one or very few kinds of different systems, this becomes impractical should the number of types increase; in fact it should be necessary to write the relative SW or FW for each kind of system; this would be a very different case from the case in which such systems were already provided with network interfaces complying with such reference model. Some networks are already extensively used on the market but they have the disadvantage of not being in compliance with such reference model (often because they came into being well before the latter) and moreover of not being able to provide high-level services.

It is desirable to realise a network which is able to provide application level services with low implementation costs and capable of being easily extended to a high number of different systems.

This specification discloses method of providing services corresponding to an application level communication protocol using services provided by a non- 0, OSI network including the steps of: a) receiving an input message, b) checking if, on the grounds of previously received messages, said message is acceptable, c) generating and sending an output message, d) calculating a state information that allows to know messages received during a previous predetermined time interval, and e) repeating steps d) wherein the number of possible values of said state information and of types of said input and output messages is limited and pre-established, and wherein said steps c) and d) are realised through pre-established tables which are dependent from the type of said non-OSI network.

Also disclosed is an interface for a network providing application level services, the interface including: means to receive input messages; means to calculate state information which characterises input messages; means to store characterisation information relating to input messages; checking means to check the acceptability of each input message by reference to the characterisation information; means to generate and send output messages.

The transformation of messages corresponding to requests for high-level services into different messages corresponding to requests for lower level services and vice versa, realised through the use of a finite state machine operating with the help of special tables, is simplified on systems of very different kinds.

IThe present invention will be better understood from the following description of a non-limiting embodiment thereof taken in conjunction with the 'l hdattached drawings in which: S' Figure 1 represents a network according to the present invention connected with two systems, and Figure 2 represents the architecture of the network of Figure 1 according to OSI criteria.

,oNetwork NW3 represented in Figure 1 provides the two systems SA, SB, connected thereto, with network services like those described in recommendations ACSE-CCITT-X.217 (Association Control Service Element) and ROSE-CCTT-X.219 (Remote Operation Service Element) and, moreover, readout, write and network file cancellation services. Network NW3 is composed of lowlevel network NW1, of a number of protocol interfaces PR equal to the number of systems connected thereto and of an equal number of bidirectional interfaces I.

L r I.

pp.. l.n i 4 The architecture of such network according to OSI criteria is shown in Figure 2; the low-level network NW1 provides upper levels with LL level services, in this instance level 1 and/or 2; the protocol interface PR by using LL level services provides upper levels with IL level services, in this instance level 3 and/or 4; the bidirectional interface I, by using IL level services, provides the upper levels, and in particular the application processes operating in systems SA and SB, with HL level services, in this instance level 7; finally, the bidirectional interface I by using HL level services put at disposal by itself provides the application processes operating in systems SA and SB with TL level services relative to file handling.

For the implementation of levels 1 and 2 a common Ethernet network is used, for levels 3 and 4 a TCP/IP protocol is used and finally a bidirectional interface, i.e. able to receive commands both from lower levels and from application proceses that require services, operating according to the method of the p.'esent invention which will be illustrated afterwards, is used for providing services corresponding to level 7. Services relative to the network handling of files (write, readout, cancellation) are realised by basing oneself on bidirectional interface services.

Such bidirectional interface, which must be present on all the systems of tq 20 the network, as well as the interface that implements the TCP/IP protocol, is advantageously implemented in SW and can be considered as a part of the operating system. It is also possible on principle and for, eg., efficiency reasons, to implement it through a HW structure, The method according to the present invention will be described now by using terminology and notations proposed by ISO (Abstract Syntax Notation o. ASN,1) and according to ISO AND CCITT standards (ISO 8824, 8649, 9072-1, 2 and CCITT X.208, X.217, X.219).

The communication services required by application processes are:.

SASSOCIATE to establish a logic connection, RELEASE to release a logic connection, ABORT-U to release in an anomalous manner a logic connection, ABORT-P to release in an anomalous manner logic connection in case of interruption of the connection, INVOKE to send interactive and, as a rule, data request, RESULT to reply with a positive outcome to an INVOKE, ERROR to reply with a negative outcome to an INVOKE, REJECT-U to reject an INVOKE, a RESULT or an ERROR, REJECT-P to inform about problem detection.

The network NW3 of Figure 1 can be seen as a service-provider and application processes operating on various systems connected therewith as service-users. A communication service involves, as a rule, the presence of two users and of the provider. In the most general case to each request for service there corresponds the sending of a request primitive (.req) from a first user towards the provider, the sending of an indication primitive (.ind) from the provider towards the second user, the sending of a response primitive (.res) from the second user towards the provider and, finally, the sending of a confirmation primitive from the provider towards the first user. Naturally every service may need only a subset of such signals. A well defined number of S"0 15 parameters, which depend also on the corresponding service, is associated with each initial signal. Moreover, a special data unit APDU for transmitting information is °,to contemplated for every service.

0' Two of the above-listed services (ABORT-P and REJECT-P) are, in contrast with all others, started by the provider itself since they are used for informing users about conditions which are anomalous and out of their control.

Interface I operates in a manner similar to a finite state machine the initial state corresponds to a wait state of a message, It repeats cyclically the following steps; a) receiving an output message, I b) checking if, on the ground of previously received messages, said message is acceptable, I c) generating and sending an output message, and d) calculating a state information that allows to know messages received during a previous predetermined time interval.

The possible values of said state information are a pre-established and limited number, and, in practice they may correspond simply to the value indicating the actual state of the finite state machine; TABLE A summarises all possible states of the special .0S 3 P< embodiments of the finite state machine.

i 6 Also the number of input and output messages are a pre-established and limited number; TABLES B and C constitute respectively the lists of possible input and output messages.

Step b) is realised by using a first table whose co-ordinates are the values of the state information and the possible types of input message and whose content of its squares is the value indicating the acceptability of the input message; the result of such check is obtained by reading out the value contained in the square whose co-ordinates are the known interface state and received message.

Step d) is realised by using a second table whose co-ordinates are the possible values of the state information and the possible types of input message and whose content of its squares is the new value of the state information a possible realisation of such a table is TABLE D.

The type of said output message is determined by using a third table whose coordinates are the possible values of said state information and the possible types of t ,'15 input message respectively and whose content of its squares is the corresponding type I of output message: a possible realisation of such a table is table E.

These three tables, from the implementation point of view can be combined in a S4' single table in which each square contains two informations: the new value of the state information, generally called "near state", and the type of output message; the third I information, relative to compliance with the request, can be represented by the absence of output message and by the new value of the state information equal to the old one.

!*.The mesage generation, as said, is realised either by one of the two users or by the provider; both the sender and the addressee can be automatically obtained from the type of message; for instance an ASSOCIATE request primitive necessarily has a first user as sender and the provider as adressee, while an ASSOCIATE indication primitive has the provider as sender and a second user as addressee. Indeed the provider requests services to TCP/IP, receives confirmation about them, is signalled with indications and provides responses: also these are messages that the interface has to handle.

7 In Figure 1, as said, there is schematically represented the network NW3, subject of the present invention, connected with two systems SA and SB and being capable of being connected with a multiplicity of systems equal to or different from SA and SB; it is constituted by a non-OSI network NW2 capable of providing lower level services and a number of bidirectional interfaces "I" equal to the number of systems connected thereto, and in which the interfaces operate according to the above described method.

The non-OSI network NW2, in this instance, is constituted by an Ethernet network NW1 provided with a number of protocol interfaces PR equal to the number of systems connected with network NW2 and therefore with network NW3 too. Such protocol interfaces PR implement the TCP/IP protocol.

The invention enables the supply of services over known networks such as ETHERNET using a known protocol such as TCP/IP and requires a software implementation of only the desired top level of the protocol, 1 t1 i i i I I i i s .yfsm-.i.i *4 o *r 4 4.

0 4 2040 04 rr 8 TABLE A STATE NAME DESCRIPTION SO Inactive S1 ASSOCIATE active, opening of TCP connection S2 Wait for response to APDU's request for ASSOCIATE S3 Closure of TCP connection after negative response from

APDV

S4 Wait for APDU's request for ASSOCIATE Wait for ASSOCIATE response from user S6 TCP connection immediate closure S7 Wait for end of TCP connection (without signalling) S8 Wait for end of TCP connection after receiving ABORT S9 Immediate closure of TCP connection (without signalling) Wait for response to APDU's request for RELEASE S11 TCP connection closure during RELEASE S12 Wait for RELEASE response S13 RELEASE collision: user A waits for RELEASE response S14 RELEASE collision: user A waits for APDU response RELEASE collision: user B waits for APDU response S16 RELEASE collision: user B waits for RELEASE response ASSOCIATE completed and wait for INVOKE or RESULT request 0 0t 1000( r i 1111111111_~ -91~1 10 154 44 6 t

I

0 4 4r 9 TABLE B M.N INPUT MESSAGE SOURCE DESCRIPTION ASSOCIATE.req User A ASSOCIATE request 11 ASSOCIATE.resp+ User A ASSOCIATE positive response 12 ASSOCIATE.resp- User A ASSOCIATE negative response 13 TCP-OPEN, ind Provider TCP connection indication from remote system 14 TCP-OPEN.conf+ Provider TCP connection positive confirmation TCP-OPEN.conf- Provider TCPconnection negative confirmation 16 AREQ User B APDU's request for ASSOCIATE 17 ARES User B APDU's positive response for

ASSOCIATE

18 ARES User B APDU's negative response for

ASSOCIATE

19 RELEASE.req User A RELEASE request 110 RELEASE.resp User A RELEASE positive response Ill RELEASE.resp User A RELEASE negative response 112 TCP-CLOSEconf Provider TCP connection closure positive confirmation 113 TCP-CLOSE.conf- Provider TCP connection closure negative confirmation 114 RREQ User B APDU's request for RELEASE 115 RRES User B APDU positive response for

RELEASE

I p. -1 ;ii 4 44

I

I I

I

f t t 44,4 I 4) 1 44 4I4 11 4 44* 4 f4.

116 RRES User B APDU negative response for

RELEASE

117 ABORT-U. req User A ABORT-U request 118 ABRT User B APDU's request for ABORT 119 TCO-ABORT.ind Provider TCP connection anomalous closure indication 120 INVOKE.req User A INVOKE request 121 ROINV User B APDU's request for INVOKE 122 RESULT.req User B RESULT request 123 RORES User B APDU's request for RESULT 124 ERROR.req User A ERROR request 125 ROERR User B APDU's request for ERROR 126 REJECT-U.req User A REJECT-U request 127 ROREJ-U User B APDU's request for REJECT-U 128 ROREJ-P User B APDU's request for REJECT-P 129 INTERNAL.req Provider State transition internal request ;i 11 TABLE C ADD; ESSEL User A M.N INPUT MESSAGE ASSOCIATE. ind

DESCRIPTION

ASSOCIATE indication *0 10 9 08 0* 9 U1 ASSOCIATE.conf User A ASSOCIATE positive confirmation U2 ASSOCIATE.conf User A ASSOCIATE negative confirmation U3 TCP-OPEN.req Provider Request for TCP connection U4 TCP-OPEN.resp Provider TCP connection positive response TCP-OPEN. resp Provider TCP connection negative response U6 AREQ User B APDU's request for ASSOCIATE U7 ARES User B APDU's positive response for

ASSOCIATE

US ARES User B APDU's negative response for

ASSOCIATE

U9 RELEASE.ind User A RELEASE indication RELEASE,conf User A RELEASE positive confirmation U11 RELEASE.conf User A RELEASE negative confirmation U12 TCP-close, req Provider TCP connection closure request U13 RREQ User B APDU's request for RELEASE U14 RRES User B APDU's positive response for

RELEASE

RRES User B APDU's netative response for

RELEASE

NOMA

i cl U16 ABORT-U.ind User A ABORT-U indication U17 ABRT User B APDU's request for ABORT U18 ABORT-P,ind User A ABORT-P indication U19 INVOKE. ind User A INVOKE indication ROINV User B APDU's request for INVOKE U21 RESULT. ind User A RESULT indication U22 PORES User B APDU's request for RESULT U23 ERROR. ind User A ERROR indication U24 ROERR User B APDU's request for ERROR REJECT-U.ind User A REJECT-U indication U26 REJECT-P.ind User A REJECT-P indication U27 ROREJ-U User B APDU's request for REJECT-U U28 INTERNAL.req Provider State transition internal request *44* tt t 4 4 a 4 4 t

II

4 t i 4i i 4 4 I c i l t E E t r a

IL

15 4 88 -4 25 14 t 13 TABLE

D

SO Si S2 S3 S4 $5 56 S7 S8 S9 Si I1 12 $6 13 S4 14 S2 so 16 17 18 S3 112 SO so so 113 so so so 117 S6 118 S8 S8 119 so so so so 129 S7 S7 $11 S12 S13 S14 S15 S16 820 19 S10 120 110 S6 S14 S6 121 Ill S20 122 112 so 123 113 so 124 320 114 S13 312 125 115 Sl Sll S16 126 116 S20 127 117 S6 S6 S6 S6 128 320 118 $8 S8 S8 38 117 S6 119 SO so so so 118 S8 129 320 119 so ML 14 TABLE E 44 .444 4 4 I 4 4 44 44 6 so Si S2 S3 S4 S5 S6 S7 S8 S9 U3 11 U7 12 U8 13 U4 14 U6 U2 16 U0 17 Ul 18 U12 112 IU2 U16 113 U2 U16 117 U17 118 U3 U3 119 U18 U18 U18 129 U12 U12 Sbo Sil S12 S13 S14 S15 S16 S20 19 U13 120 110 U14 U14 ___U14 121 U19 Ill 122 U22 25 112 Ulo 123 U21 113 Ulo 124 U24 114 U9 U9 125 U23 115 U12 U12 U10 126 U27 116 Ull 127 117 U17 U17 ___U17 U17 128 U26 118 U12 ___U12 U12 ___U12 117 U 17 119 U18 ___U18 U18 U18 118 U12 129 U26 119 U18 44 4 41 I C C 44 '4

Claims (11)

1. A method of providing services corresponding to an application level communication protocol using services provided by a non-OSI network connecting two or more stations, the method including the steps of: a) receiving an input message at a first station, b) checking if, on the grounds of previously received messages, said input message is acceptable, c) generating and sending an output message the output message being determined by the input message and the state of the station, d) calculating a state information that characterizes messages received during a previous predetermined time interval, and e) repeating steps d) wherein the number of possible values of said state information and of types of said input and output messages is limited and pre-etablished, and wherein said steps c) and d) are realised through pre- S '1 5 established tables which are dependent from the type of said non-OSI network. i t

2. A method as claimed in claim 1, wherein said step b) is realised by using a first table whose co-ordinates are the possible values of said state information and the possible types of input messages respectively and whose content of its squares is the value indicating the acceptability of said input message. i

3. A method as claimed in claim 1 or claim 2, wherein said step d) is realised by using a second table whose co-ordinates are the possible values of said state information and the possible types of input messages respectively, and whose content of its squares is the new value of said state information.

4. A rmei'hod as claimed in claim 1, wherein the type of said output message is determined by using a third table whose co-ordinates are the possible valuos of said state information and the possible types of input message respectively, and whose content of its squares is the corresponding type of output message. A method as claimed in claim 1, wherein the sender of said input message depends on said input message, and the addressee of said output message depends on said output message.

6. An interface for a network providing application level services for a first station Sconnected to one or more other stations via a non-OSI network, the interface including: 16 means to receive input messages; means to calculate state information which charadcterises the state of the first station; means to store charadcterisation information relating to first station; checking means to check the acceptability of each input message by reference to the characterisation information; means to generate and send output messages, the output message being determined by the input message and the state of the station.

7. An interface as claimed in claim 6, wherein the means to store characterisation information takes the form of an acceptability table a first co-ordinate of which is the possible values of said state information and a second co-ordinate of which is the possible types of input messages, the contents of the table being a value indicating the acceptability of an input message.

8. An interface as claimed in claim 6 or claim 7, wherein the means to c t charadcterise input messages includes a new state table a first co-ordinate of which comprises the possible values of said state information, and a second co-ordinate of I It 4 which comprises possible types of input messages, the contents of the second table t being a new value of the state information.

9. An interface as claimed in any one of claims 6 to 8, wherein the output messages are determined by using output message table whose first co-ordinate comprises the possible values of the state information and whose second co-ordinate comprises the possible types of input messages, the contents of the third table i comprising the corresponding output messages, An interface as claimed in any one of claims 6 to 9 wherein the means to I t 25 calculate recalculates the state information on receipt of each input message.

11. An interface for a network providing application level services substantially as herein described with reference to the accompanying drawings.

12. A network including an interface as claimned in any one of claims 6 to 11.

13. A method of providing application level services in a network, the method being substantially as herein described with reference to the accompanying drawngs, DATED THIS THIRTIETH DAY OF AUGUST 1995 ALCATEL N.V. i ABSTRACT An interface for a non-OSI network for providing application level services, the interface including; receiving means to receive input messages, characterisation means to calculate state information from input messages; verification means to verify the acceptability of input messages based on previously received messages; means to generate an output message; the receiving means, the characterisation means, and the verification means each including a respective table, the contents of the tables being determined by the type of network. a Il I I t a s I it L 1 ii. m