Between the 1970s and the 1990s, there was a lot of debate between organizations, nations, and engineers to find a suitable communication protocol that would enable the best cross-boundary interconnected networking solution. This was also known as the protocol wars.
The protocol wars were won by the Internet Protocol Suite (TCP/IP), which was developed by the Internet Engineering Task Force (IETF). You can read more about it in my previous post. Another big contender was the Open Systems Interconnection (OSI) model. This model was created by the International Organization for Standardization (ISO). You probably have heard about some sort of ISO standard before, because the ISO standards organization develops international standards for a lot of things, spanning across various industries and countries.
The question is why are the other losing contenders, of the protocol wars, not so widely known/adopted by the global IT community?
The TCP/IP model already won the first prize for its use in the internet, but neither the TCP/IP model or the other contenders contributed what the OSI model did: The OSI model did a spectacular job of simplifying networking concepts. This made it the standard reference model used to discuss, design and teach networking fundamentals in the classroom as well as in the workplace.
The OSI model provides a similar layered architecture approach as TCP/IP, but more specifically forms a basis for ISO standards for systems interconnection. It also provides additional layers, which give just enough granularity to be quite useful in explaining different stages of the network communication chain.
The OSI model specifies seven abstraction layers versus the four abstraction layers specified by TCP/IP. The image below shows the layers side-by-side, grouped by function using four distinct colors. The center column also provides some examples of the types of protocols used by each layer. This depiction highlights the fact that in using the OSI reference model, one can differentiate more between different protocols used within the functional networking layers.
The picture above shows mostly TCP/IP Protocols in the center column. There are quite a few OSI Protocols specified by various ISO standards, and can be seen in the table provided here.
Additionally to protocols grouped by each layer, network devices such as switches, routers, gateways, etc. are also generally grouped or reffered to their use by the OSI reference model layers. This also makes sense due to the fact that each network device implements a network protocol(s) in the stack.
The application layer is a data layer which enables applications to communicate with other applications. Like the HTTP protocol used by your browser application to display this blog post can communicate with the web server application which supports HTTP requests.
The presentation layer is a data layer which defines data formats. This is where encryption (e.g. SSL) and compression takes place. Your browser will, for example, encrypt the HTTP request using SSL, where the combination is commonly reffered to as HTTPS. This enables end-to-end encryption between the browser application and the web server application, which means you can safely browse the web, make requests and read responses accross the internet.
The session layer is a data layer which establishes and terminates a connection session between two different systems. This happens, for example, when you make a request, using your browser, to the web server, hosting this website. When this connection is established a network socket is created. A network socket is a combination of the underlying transport protocol (e.g. TCP), the IP address and port number. This serves as an endpoint for sending or receiving data within a network.
The transport layer is a segment/datagram layer. This means it takes the data from the layers above and encapsulates it into e.g. a segment (TCP) or datagram (UDP). This is also where services such as flow control and delivery reliability plays a big role. In our browser request example, the HTTPS Protocol Data Unit (PDU) is encapsulated into a TCP segment. The transport layer will then ensure that it is received correctly and at a suitable rate of transmission between both sides of the connection.
The network layer is a packet layer. This layer ensures that the segment/datagram received from the layer 4 is chopped up into packets and forwarded to the correct address using the correct and most optimal routes. This layer uses logical device addressing, e.g. using an IP address. The network layer can also decide to transmit packets through different available routes, which makes data transfers much more efficient.
The data link layer encapsulates the network packets into frames. The frames are based on the specific protocol (Ethernet, Wi-Fi, etc.) used between the two physical connection nodes. This layer provides the functional basis which enables transport of a frame accross a physical medium. The data link layer is commonly divided into two sublayers:
The physical layer uses bits and provides a physical medium to transport data accross. It defines how cables, transmitters and receivers, send and receive bits (i.e. ones and zeros). This layer uses for example an ethernet cable (RJ45 <-> UTP Cable <-> RJ45) to physically connect two ethernet supported network interface controllers (NICs) to each other. The combination in this example of "NIC-cable-NIC" comprises the physical layer.
During the 1970s to 1990s the debate on which communication protocol stack would be the best suited for use in the internet resulted in the protocol wars. Even though the TCP/IP model was crowned victorious for use in the internet, the OSI model won the use as standard reference model in discussions, design and education of IT networks.
The OSI model functionally groups the vast amount of communication protocols into seven categories. These categories make it easier to design and understand complex information technology infrastructures all the way from the physical layer to the application layer.
Feel free to comment below or get in touch with me through the contact form.
Husband, Lifelong-Learner, Team-Player & Systems Engineer