The ISO Reference Model of Open Systems Interconnection

Leslie Jill Miller
1981 Proceedings of the ACM '81 conference on - ACM 81  
1.0 Introduction During the 1970's computing facilities which had previously provided stand-alone processing were linked into a variety of networks under quite different geographical, technical, financial and application constraints. The effect of these independent developments was that similar services were often provided by quite different mechanisms, and interconnection became extremely difficult. Late in the 1970's a strong desire for a standard means of internetwork communication arose. It
more » ... was realized that a common model of distributed data communications would be required to facilitate the development of these standards. Intensive activity was initiated by several national and international standards organizations, including the International Organization for Standardization (ISO). In 1978 the "Reference Model of Open Systems Interconnection" [8] was produced, and this led to the 1981 Draft International Standard 7498 "Data Processing -Open Systems Interconnection -Basic Reference Model" [2]. The documents assume an environment of systems which make themselves "open" to the exchange of data with other systems by adhering to a well-defined set of standard procedures for communication. The documents' scope includes not only the basic transfer of information between such systems, but also the capability of such systems to work together in support of distributed applications. The Open Systems Interconnection model is intended to facilitate standards development and is primarily aimed towards the writers of future standards in e,~ch of the areas outlined by the reference model. Interest in the model, however, has increased enormously and several tutorials have been written on the model and associated standards activities [3], [7], [11]. This tutorial is much more intutive in nature and is intended as a first tutorial for the reader with only a minimal background in network communication. It begins by motivating the set of required services and then discussing how certain architectural features are supported throughout the model as a whole. The next section gives a very informal introduction to some common services needed to support communication within a distributed environment. The services are introduced, as required, in order to get messages from one mythical kingdom to another in Medieval times. Despite the out-of-data imagery, the communication techniques used and the conceptual model developed are directly analogous to those of the ISO reference model. In section three the seven layers of the ISO model are briefly described. A set of functions which are important across several layers of the model is then discussed in section four. These include connection management, data transfer, and error detection and correction. 2.0 Diplomatic Communication in Medieval Times This example deals with the two Medieval kingdoms of Altdorf and Btitzen. The two kingdoms have traditionally been enemies and as a result the only communication between them consists of itinerant peddlers who carry a few goods back and forth across the long and hazardous path between them. The day arrives, however, when a new King comes to the throne of AItdorf and decides to propose an alliance with the kingdom of Blitzen. Thus, he writes a letter to the King of Blitzen, and commands his Foreign Minister to see that it is delivered. This is a typical case of an entity in one system wishing to communicate with an entity in another system. As in today's communications environment, there are difficulties in sending minimal communications of any sort between the two end systems, and there are also problems of reliability, language differences and etiquette to overcome. The Foreign Minister of Altdorf is somewhat more experienced in diplomacy than.the young King, and he decides to ensure a favorable reception before actually sending the King's own words to these traditional enemies. He keeps the King's letter for the time being, and writes his own letter to the Foreign Minister of Blitzen, inquiring as to whether that kingdom is willing to establish diplomatic relations with Altdorf. Having Connections are often established at different layers. In this example, the Foreign Ministers explicitly establish one such connection. Messages tend to proliferate in managing connections and providing reliability. Meaningful information at one layer is encapsulated within lower layer messages, but is treated as uninterpreted data by those layers. This section has introduced the types of services required to support communication during those difficult Medieval times. It introduced layering as an appropriate tool for managing the complexity of the full set of services. The next section presents a very similar but more general model for interconnecting "open" systems which was developed by the International Organization for Standardization. Basic Reference Model of Open Systems Interconnection The Basic Reference Model for Open Systems Interconnection postulates that each system include seven logical subsystems, each communicating with its next lower and next higher subsystems. The set of all subsystems at the same level across all systems is collectively referred to as a layer in the architecture. Each layer invokes certain services of the next lower layer, and each provides services to the next higher layer. The flow of information between peer entities within a single layer is governed by a layer-specific protocol which specifies the rules for exchanging information and the formats for the required messages. Information is exchanged via protocol-dataunits consisting of control information and optional higher-layer data. Layer N protocol-data-units are actually transmitted between peer entities by encapsulating them as uninterpreted data within layer N-1 protocol-data-units, just as the King's letter was encapsulated within the Foreign Minister's letter. Only at the lowest layer is there direct communication via the physical media connecting the two open systems. Within one system, interface-data-units are passed across interfaces between the layered subsystems. Information thus originates at the highest layer of the source system; successively passes down through several interfaces, at each layer being further encapsulated within that layer's protocoldata.unit; is actually transmitted from source to destination system at the lowest layer; and then successively passed up through several interfaces at the destination system, at each layer having encapsulating headers removed until the original protocol-data.unit arrives at the highest layer. Although this layer was not present in our Medieval example, it is easily introduced. Assume that the people of Altdorf speak French and those of Blitzen speak German, but that Priests in both kingdoms speak Latin. The functions of the Presentation Layer could be carried out by a Priest at Altdorf translating the King's letter from French into Latin, and a Priest at Blitzen translating from Latin into German. The language of communication is Latin but the Presentation entities at each end present the semantics of the communication in the syntax desired by the Application Layer entities. The Session Layer, Layer 5, supports a session administration service which provides for the binding and unbinding of two Presentation entities into a logical relationship called a sessionconnection, and supports a session dialogue service within the session-connection. This session dialogue service controls data exchange by delimiting and quarantining data, synchronizing the data exchange, and managing the sequencing of interactions. Within an interconnected open system, it is the session. connection established between users and providers of services that carries accounting and access control information. In the Medieval example, the Foreign Minister Layer corresponds to the Session Layer, with diplomatic relations corresponding to the session-connection, and diplomatic conventions corresponding to the interaction management. Layer 4, the Transport Layer. is intended to provide transpareht, reliable and cost.effective data transfer end-to:end between the source and destination systems. The quality of service is selectable, with the Transport Layer selecting or enhancing the underlying Network services so as to provide the class of service requested by the Session entity. Examples of highly reliable transport protocols which provide sequenced, flow. controlled delivery of data include the Department of Defense's connection-oriented Transmission Control Protocol (TCP) [5], and the transaction-oriented Delta.t protocol [10] used on the high performance local network called Octopus at Lawrence Livermore Laboratories. The Transport protocols being developed by ISO [9] provide for five different classes of connection-oriented service, ranging from minimal Teletex compatible service up to service comparable to that provided by TCP. The Purchasing Agents in our Medieval example correspond to Transport entities, enhancing the basic delivery service of the underlying Peddler network through their acknowledgement and retransmission protocol. Layer 3, the Network Layer, provides the means for routing data between systems containing communicating application entities. It handles the routing, switching and relaying of data within a single administrative network or over parallel or tandem subnetworks combined to form an internetwork, and it provides these transfer services at a known cost. CCITT's X.25 is a well known network interface standard, but there are few standard network protocols. There are, however, standard internetwork protocols such as those for handling the datagrams of the Department of Defense Internet [4] and the Xerox Pup architecture [1]. The Medieval example breaks down somewhat for the lower layers of the ISO Reference Model, with the Peddler Layer providing the services of the three lower layers, either through individuals carrying the Purchasing Agents' messages themselves or passing them on to fellow Peddlers for delivery. Layer 2, the Data Link Layer, involves the transfer of logical blocks of data across a link in such a way as to mask the physical characteristics of Layer 1. While different degrees of error detection and correction for these blocks of data may be provided by different link layer protocols, a primary motivation for including this layer in the architecture is to allow for localized identification and correction of transmission errors across individual links. The layer provides functional and procedural means for managing Data Link connections and may provide capabilities for controlling circuit switching. Typical protocols at this layer are IBM's SDLC, ISO's HDLC, ANSI's ADCCP, and X.25 LAPB. Layer 1, the Physical Layer, is concerned with the actual means of bit transmission across a physical medium. It provides the mechanical, electrical, functional, and procedural functions necessary to transmit and interpret signals sent across the physical medium between such entities as terminals, computers, modems and network switches. Typical protocols at this level are EIA's RS 232.C and RS 449, which provide for the transparent flow of bits across a physical medium. The above description has been very cursory but it indicates the primary importance of layering as a structuring tool in defining systems which are "open" for communication, and it outlines the services which each layer is intended to support. 4.0 Common Protocol Functions Protocols at different layers of the reference model include such common functions as connection management, data transfer and error detection and correction. This section illustrates the variety of protocol capabilities in each of these threee areas. The design of an efficient communication system based on layered protocols requires that the different protocols provide complementary services which avoid replicating identical functions. Connection Management The current ISO Reference Model for Open Systems explicitly established and released at each layer in order to support inter-system communication. The establishment of such a connection typically requires at least a message in one direction requesting a connection, and a second in the other direction agreeing to the connection. User data may or may not be carried by the connection establishment request and response. Different protocols also differ in the reliability of the connections which they establish, especially in their ability to differentiate between different instances over time of the desired connection. ( A connection may be broken and re-established. The problem arises if data from the old connection instance arrives after the new connection is established.) Protocols also differ in their provision of a "graceful close", only terminating the connection after all transmitted data has been received at the destination. Typically connections at the higher protocol layers pay the price of more complex connection management schemes to get better performance. Lower layers can be less careful since any errors will be caught later at the higher layers. The connection management required by the Reference model involves a large overhead. Alternatively, at most of the layers it is also possible to employ connectionless protocols, and it is expected that extensions to the current Reference Model will incorporate this fact. The Ethernet Data Link Protocol [6], for example, specifies that the destination should accept single autonomous frames addressed to that work station; there is none of the state-saving required for connections being maintained between protocol-data-units at that layer. At Layer 3 there may be connections such as the virtual circuits of an X.25 network or X.75 internetwork, or information may be transmitted in independently routed, unrelated datagrams such as occurs in the Department of Defense Internet and the Xerox Pup Architecture. At the Transport Layer connections are almost always established to achieve the desired reliability for blocks of data. The Delta-t protocol used on Lawrence Livermore Laboratory's Octopus Network is unusual in being transaction oriented, supporting the reliable delivery of smaller pieces of usually independent data. Similarly, there exist protocols at higher layers which mimic the effect of procedure calls, with minimal state-saving between calls. The model explictly includes multiplexing of connections. This allows for many higher layer connections to be mapped into one lower layer connection, as occurs in X.25 when one Physical
doi:10.1145/800175.809901 dblp:conf/acm/Miller81a fatcat:xrmm54e4f5aklk7644thxaxyl4