Higher-level protocols are not necessary end-to-end

The higher-level communication protocols in computer networks, such as belonging to the OSI Transport through Application layers, are usually considered to have an end-to-end significance, that is the entities executing the protocol reside at the two respective ends of the connection, close to the application users. This question of end-to-end significance was in particular an issue in the discussion of the meaning of acknowledgements in the Transport layer, and in the distinction between the OSI Network and Transport layers. The OSI protocols are developed for the interworking of "Open Systems". It seems that an Open System may be, in particular, a distributed computing system which presents to its environment, for example through a gateway, the protocol behavior defined by OSI. In this case the Open System would use internally, possibly over a local area network, specific protocols, which may or may not be structured according to the OSI Reference Model, but which are different to the protocols defined for OSI. In this case the OSI higher-level protocols would be executed between the entities in the environment of the Open System (e.g. system of user A1) and the gateway of the Open System, which is not end-to-end, as indicated in the figure below. The purpose of this contribution is to point out that this situation can be considered normal (i.e. end-to-end significance is irrelevant) provided that the OSI services have a property, which we call in the following "concatenation property". A service specification has the concatenation property if two service providing subsystems may be concatenated such that the system (consisting of the concatenated subsystems) provides a service which has the same logical properties as the original services. (Clearly, the performance of the concatenated service would in general be lower). It is important to note that we assume that the services of the non-OSI system (e.g. service provider B) are logically identical to those defined for OSI (e.g. service provider A). In this case the concatenation entity has a straightforward function (see below). In the case that they are different, some adaptation may be performed which has, however, an impact on all users and could sometimes result in quite complex gateway functions. The OSI Transport service has the concatenation property to a large extent. It is sufficient to use a concatenation entity that generates service requests to the service provider B for each service indication received from service provider A (with same parameter values). A problem arising, however, is one of addressing. It is necessary that the addressing space within the service provider B be foreseen by the addressing conventions used within the service provider A (and inversely) such that a user connected to the service provider A may select an address which identifies a user connected to the service provider B. It is then necessary that all service indications generated by service provider A destined to users connected to service provider B be generated over the interface to the concatenation entity, and similarly in the opposite direction. Another problem is related to error reporting. It seems that a distinction between connection aborts generated by the user or service provider, respectively, is not possible in the manner defined for OSI. It seems that the services specified for the other higher layers of OSI have similar concatenation properties. We can see two conclusions from the above discussion: (1) If services have the concatenation property the question of end-to-end significance is irrelevant. Gateways may be constructed which realize the concatenation of two or more distributed system services. (2) The service specifications of OSI are the main documents on which the construction of OSI gateways is based. These specifications are therefore essential, not only as a basis for checking the consistency of several protocol layers within the OSI hierarchy, but also as as basis for interworking between existing systems according to OSI.