OSI is an architectural model for open networking systems that was developed by the International Organization for Standardization (ISO) in Europe in 1974. The Open Systems Interconnection (OSI) reference model was intended as a basis for developing universally accepted networking protocols, but this initiative essentially failed for the following reasons:
The U.S government tried to require compliance with the OSI reference model for U.S. government networking solutions in the late 1980s by implementing standards called Government Open Systems Interconnection Profiles (GOSIPs). This effort was abandoned in 1995, however, and now few real-world implementations of OSI networking protocols exist outside of Europe.
The OSI reference model is best seen as an idealized model of the logical connections that must occur in order for network communication to take place. Most protocol suites used in the real world, such as TCP/IP, DECnet, and Systems Network Architecture (SNA), map somewhat loosely to the OSI reference model. The OSI model is a good starting point for understanding how various protocols within a protocol suite function and interact.
The development of OSI standards, i.e. standards for the interconnection of real open systems, is assisted by
the use of abstract models. To specify the external behavior of interconnected real open systems, each real open system
is replaced by a functionally equivalent abstract model of a real open system called an open system. Only the
interconnection aspects of these open systems would strictly need to be described. However to accomplish this, it is
necessary to describe both the internal and external behavior of these open systems. Only the external behavior of open
systems is retained for the definition of standards for real open systems. The description of the internal behavior of open
systems is provided in the Basic Reference Model only to support the definition of the interconnection aspects. Any real
system which behaves externally as an open system can be considered to be a real open system.
Data presentation and session management are important concepts, but it has not proved necessary, or evenparticularly useful, to make them into true layers, in the sense that a layer communicates directly only withthe layers adjacent to it. (SSL/TLS, 22.10.2 TLS, might be an example of a true layer providing encryption;applications read and write data directly to the SSL/TLS endpoint, which in turn manages the TCPconnection.) Generally what happens is that the Application layer manages its own Transport connections,and then reads and writes data directly from and to the Transport layer.
The application then uses conventionallibraries for Presentation actions such as encryption, compression and format translation. Similarly,applications typically implement their own Session actions for handling broken Transport connections, or for multiplexing streams of data over a single Transport connection. Version 2 of the HTTP protocol, forexample, contains a subprotocol for managing multiple streams; this is generally regarded as part of theApplication layer.
OSI has its own version of IP and TCP. The IP equivalent is CLNP, the ConnectionLess Network Protocol,although OSI also defines a connection-oriented protocol CMNS. The TCP equivalent is TP4; OSI alsodefines TP0 through TP3 but those are for connection-oriented networks.
It seems clear that the primary reasons the OSI protocols failed in the marketplace were their ponderousbureaucracy for protocol management, their principle that protocols be completed before implementationbegan, and their insistence on rigid adherence to the specifications to the point of non-interoperability. Incontrast, the IETF had (and still has) a «two working implementations» rule for a protocol to become a«Draft Standard». From RFC 2026:
A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the «Draft Standard» level.
This rule has often facilitated the discovery of protocol design weaknesses early enough that the problemscould be fixed. The OSI approach is a striking failure for the «waterfall» design model, when competingwith the IETF's cyclic «prototyping» model. However, it is worth noting that the IETF has similarly beenunable to keep up with rapid changes in html, particularly at the browser end; the OSI mistakes were mostlyevident only in retrospect.
Trying to fit protocols into specific layers is often both futile and irrelevant. By one perspective, the RealTimeProtocol RTP lives at the Transport layer, but just above the UDP layer; others have put RTP into theApplication layer. Parts of the RTP protocol resemble the Session and Presentation layers. A key componentof the IP protocol is the set of various router-update protocols; some of these freely use higher-level layers.
Similarly, tunneling might be considered to be a Link-layer protocol, but tunnels are often created andmaintained at the Application layer.
A sometimes-more-successful approach to understanding «layers» is to view them instead as parts of a protocol graph. Thus, in the following diagram we have two protocol sublayers within the transport layer (UDP and RTP), and one protocol (ARP) not easily assigned to a layer.