To explain the OSI-model, let’s start with an example. Bob wants to send stroopwafels to Alice. Bob (of course) lives in the Netherlands. Alice lives in the USA. For the stroopwafels to arrive at Alice, Bob needs to package them. He puts them in a box and puts a label with an address on the box. The address is formatted according to international agreements. Bob brings the package to the post office. Here he gets the option to either choose for reliable delivery, or unreliable delivery. Once the postal service has the package they can choose to send the package by plane or by boat to the USA. After a while in transit the package is delivered to Alice. She verifies that her name and address are on the package and opens it.
The story of Bob and Alice looks a bit like an application that wants to send a message across the network. It doesn’t matter to Bob whether the package is sent by plane or by boat (though it would be a shame if the stroopwafels pass their expiry date). Bob just wants to know for sure that the package arrived. Real world examples are always a bit simplistic, but the interfaces between these layers are there in the story too. Bob has to make a decision whether to send the package in a reliable way or not. He does not care how the postal service realises this. He also doesn’t care whether the package is delivered by UPS, USPS or Fed-Ex once it is in the USA.
Network applications work a bit like this example. The application has something it needs delivered to another system, so it asks the network to take care of this. Before the OSI and TCP/IP models existed a programmer needed a lot of intimate knowledge of networking to get the application to do this. That’s why these models were defined. This way the programmer doesn’t need to know how to send data on a radio link versus a wired link. It doesn’t matter whether the network is IPv4 or IPv6, etc.
The ISO OSI model
Back in the seventies there weren’t any models that would define these layers and interfaces between the layers. The International Standards Organisation set out to define a model for this. The model became the OSI model, which stands for Open Systems Interconnection. This model consists of seven distinct layers and interfaces between these layers. The image below shows these layers.
- Layer 7, Application: This is where the application itself resides. This is the layer that takes care of the interaction with the user of the system. User in this case does not need to be a human.
- Layer 6, Presentation: The presentation layer is a layer that is often misunderstood. It is the layer that defines the way the date should be interpreted. That means that it defines things like data compression and decompression and data formats like XML and JSON.
- Layer 5, Session: This layer keeps track of sessions in the datacommunication. This is also a often misunderstood layer. The reason for this is that this layer (and the presentation layer) doesn’t exist in the TCP/IP model and sessions are therefore managed by different layers in the model. Something that could happen in a session layer is neighbor adjacency status tracking for a routing protocol
- Layer 4, Transport: This is often compared with the TCP and UDP options within the TCP/IP model. The transport layer defines things like reliability, flow control and error control.
- Layer 3, Network: This layer concerns itself mostly with addressing and finding the destination in global networks. This means routing in larger networks.
- Layer 2, Data-link: Datalink is used for system to system communications. So transporting data within a segment. For this it manages the different protocols that can exist for communication between two systems, such as Ethernet and ATM. But also WiFi lives for a large part in this layer.
- Layer 1, Physical: The physical layer concerns itself with the way bits are transported on the wire. It governs things like voltages and timing between bits.
The OSI model is used as a reference model. It is primarily a study source, but very helpful to understand layers in networking. The layers might not be implemented in a 1:1 manner, but being aware of these layers is very helpful.
The TCP/IP model
The TCP/IP model is what is actually implemented at this moment. It could have been the other way around, but because IP became the most popular protocol, the accompanying model also became the de facto model.
The model is very similar to the OSI model, but differs in some slight ways. Look at the image for this.
As you can see the TCP/IP model has an application layer like the OSI model. However, this model spans the Presentation and Session layers as well. That means that anybody wanting to create an application based on the TCP/IP model must implement session and presentation functions in the application itself. Luckily you can use libraries for this, but it is the responsibility of the application programmer to do this.
The Transport layer is the same as in the OSI model. This is where TCP and UDP live. The network layer is called the internet layer in the TCP/IP model, but their functions are the same. The TCP/IP model combined the physical and data-link layers.
This is also where the OSI model returns to our daily lives. When you troubleshoot a network, or when you are configuring switching you will discuss ‘Layer 2’. In the TCP/IP model, layer 2 would refer to the Internet layer, but that’s not what we mean with layer 2. Whenever somebody refers to a layer with a number they are referring to the OSI model and not the TCP/IP layer.
In fact, it’s a good idea to learn both layers, but on a day to day basis you will likely discuss OSI model layers more often than TCP/IP model layers.
Layers in action
The image below is a traffic capture of a HTTP request packet. You should notice right away the amount of lines you see. Five of them in total. The TCP/IP model covers 4 layers and the OSI model covers 7. So 5 differs from both of them. This immediately shows the difference between models and real life. What you see here are the Physical, Data-Link, Network, Transport and Application layers. So a combination of both OSI and TCP/IP models.
Physical layer
Let’s first zoom in to the physical layer. What can we see here?
Not too much information. The reason for this is that when you capture this data most of the real physical level stuff has already been processed. We won’t be able to see things like codecs that govern bit patterns, voltages and the like. What we can see is that the physical layer refers to Ethernet. Which is the protocol used on layer 2. So let’s zoom in to layer 2 next.
Data-Link layer
The data-link layer gives us a bit more information. We can see the source and destination mac addresses of the connection. This traffic is directed from my Apple iMac to my modem. The server itself is out on the Internet, but data-link layer communication is always local. Again we can see the next layer protocol, which is IPv4 in this case.
Network layer
On the network layer we can see a lot more. We can see a source IP address and a destination IP address. We can also see things like the Differentiated Services Code Field, which is used for Quality of Service. There are several flags and a Time to Live. This ensures that the packet will be discarded in the end if it fails to reach its destination in 64 ‘hops’. Again the next layer is defined, being TCP in this case.
Transport layer
The transport layer in this case is TCP. That means that the application requested a reliable delivery. We can see a source and destination port. These are used to establish sessions, which in the OSI world would have been done by the session layer. We can see sequence numbers and acknowledgements. These are used to provide the reliable transport. Same goes for the checksum, which is used to verify whether the received frame was not modified in transit.
You might notice it does not refer to an upper layer protocol. That’s because TCP does not know about any upper layer protocols. It also doesn’t matter for TCP, as the end system will handle that based on the destination port. These ports are mapped to applications, so it will cause the packet to be delivered to the right application.
Application layer
The application layer contains the application specific information. This can be anything a programmer thought of. In this case the application is HTTP. It contains information required to process the HTTP request on the server.
