Interpret the open systems interconnection model
It's useful to think of the OSI model as an abstraction that allows us to infer the separation of concerns on the network.
Translated from Deciphering the Open Systems Interconnection Model by Laura Santamaria.
Unless you've studied networking certification, the Open Systems Interconnection (OSI) model may seem somewhat mysterious to you. Maybe you've heard about it from a colleague, or maybe you've seen it in a marketing campaign for a product on AWS.
Maybe you think "Tier 3" is just a new buzzword. However, such shorthand references to the OSI model, if you can decode them, can be useful because they can help you understand where the network stack might fit into the tool, or where to look for problems during an incident call.
Before we dive in, let me address a controversial issue. Many would say that the theoretical OSI model is outdated. The model is theoretical, it's true, and the real world is certainly much more complex than it might make you believe. Its layers don't correspond perfectly to specific devices, and other models exist that more accurately reflect the real world, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) model.
Image
It's useful to think of the OSI model as an abstraction that allows us to infer the separation of concerns on the network. We use it to think about troubleshooting steps when our data doesn't reach its destination, and we use it to think about architectural needs when we build distributed systems.
It is not a theorem with strict boundaries and rules. It is a theory that we find in systems science: trying to approximate the real world to help us understand it better.
Layered in detail
To understand the model, let's track data from your computer to another system and explore how it changes along the way. Let's say you're using your computer and need to chat with a colleague. You open your chat app and write a message. Data movement begins, and when you send it, the OSI model comes into play. The top four layers of the model are called the "host layer", and since we're on the host (your computer), we'll start this exercise here.
Host layer
Host layer
Layer 7: Application layer
Let's start with Layer 7, the application layer. "App" here does not necessarily refer to your chat application, but rather to the implementation of the protocol it uses to send messages. For example, the protocol might be WebSocket. Other protocols in this layer include SMTP (Simple Mail Transfer Protocol) for email applications or HTTP (Hypertext Transfer Protocol) for web browsers. The application or API you use uses these protocols to accept data. In this case, your chat application implements logic to receive the data you use and identify the correct transport protocol.
Layer 6: Presentation layer
Once your application recognizes the correct protocol, the data drops down to layer 6, the presentation layer. At the presentation layer – it's still on your machine, maybe even in the same application! - The data is converted into the correct protocol. For example, if you're sending a GIF, the presentation layer takes the display format and encodes it for transmission over the network. Since we are in a chat app, chats may also be billed as encrypted communications. Data encryption also happens at Layer 6, and compression can also happen when you send an image.
Layer 5: Session layer
And then we go down to layer 5, the session layer. (We're still on your computer.) If you've just opened your chat app, you may need to log in. Layer 5 is where we open the session and authenticate. If you've developed or maintained applications with sign-in or authentication requirements, you're probably familiar with user sessions. The video or audio conferencing application opens the session when it starts a call and closes it when the call is terminated. In this case, when you log in to the app, it sets up and sends the first of a series of calls and responses to establish a connection. Depending on the architecture of the application, when you send a direct message with a colleague, another session may be opened.
Layer 4: Transport Layer
Note that we've reached the fourth layer and still haven't left the host! In this abstract world, no data leaves your computer, it's still just a bunch of data with no specific direction. That's about to change. The fourth layer, the transport layer, is the last layer in the host. Here, the data begins to be packaged and ready for transfer. The formal term for this packaging is "encapsulation". (On the receiving end, data is "decapsulated" as it moves from a lower layer to a higher layer.) At the fourth layer, such as a TCP/IP connection, once the data reaches the target machine (the destination port), it gets a port number to use, and the port number from which it will leave (the source port). At this point, the data and its headers are referred to as segments. The segment from here flows into the stream of data that will leave your PC, so the header of all the metadata generated here is critical to parsing it back to the right service on the other end: your colleague's chat application.
Media layer
The bottom three layers are called the media layer. The term "media" here refers to hardware, and these layers work primarily on hardware that is dedicated to the network.
Layer 3: Network
In the third layer, the network layer, the data is usually broken down into smaller chunks, called packets, in order to be transmitted. Each packet carries a header that contains the host address and the final destination address (usually an IP address if transmitted over the Internet). In terms of hardware, the third layer is usually represented by a router. The final destination address is usually part of the routing table stored by the device. A router uses a routing algorithm to decide the best path to reach its destination because it is usually more than one step away and packets are frequently forwarded from one router to another.
Layer 2: Data link layer
After getting the IP address by referring to the routing table, we go down to the second layer, the data link layer. Here, your MAC (Media Access Control) address is added to the header of the data as the source address, and then the system tries to identify which device should be the next stop for the data to reach its final destination. Once it has the MAC address of the intermediate connection, the system adds that MAC address as the destination address to the header, creating a frame. The system then identifies the port from which the frame is to be sent and prepares to descend to the first layer. If we associate different layers with different hardware parts, the physical box of this layer will be the switch, which holds a table of MAC addresses that maps each physical port to a specific MAC address. There is always a port that is saved as a universal port, and everything that is not in the table is forwarded.
In our example, there is no standalone switch involved at this stage. The logic for the second layer (and the third, technically) is inside your computer. Layer 2 logic and the use of Layer 1 ports used to be part of physical hardware called network interface cards (NICs). If you've built a desktop before, you probably know it as a network card. (You may remember connecting the network card to the motherboard via the bus or plugging in a dongle.) Most user systems now have this interface built into the motherboard or system-on-chip. However, in a larger environment, such as an office network, there may be a switch (or switch-router combination device) at the second layer.
Image
Finally, we descend to the first layer, the physical layer. Data can now be moved! Data always moves through the physical layer in the form of a stream of bits (a stream of 0s and 1s), which can mean a physical cable or a wireless connection. However, if you are connected to the internet, the data must pass through a physical cable at some point. The largest cables in the first layer form the backbone of the Internet: huge bundles of fiber and copper cables that run underground and under the ocean between different centers around the world. The backbone meets at the exchange point, and data is transferred from one ISP or network to another. Since there are many exchange points and networks, there are many routes, and this is where transportation becomes complicated.
transmit
In fact, your data travels along a variety of different paths. It goes through all the OSI layers on your laptop and then jumps to your wireless access point via a Layer 1 connection. After that, it may go up to Layer 2 inside the access point to get a new MAC address destination and then go down to Layer 1 again, jumping to a switch that forwards data to the router. The router then queries its routing table to decide which port to use. Assuming your data needs to be transmitted over the internet, the router will send it to your ISP and transfer it through layers to layer 1. It may also be sent to another router, which will then send it to its destination in a skip manner. The device can handle multiple OSI layers, so if you try to track it, this conceptual model may fail. If you're using a VPN, things get even more complicated when your data travels over the internet.
Once your data arrives in the right system, it starts to go up to your colleague's computer. It may go through a switch or router (or both!). ) to the right machine and move up the floor, from 1 to 7. As it moves up, the header is stripped during the decapsulation process, and the data is reassembled, decrypted, and converted into something understandable to the application. Finally, your cat GIF appears on your coworker's screen.
Image
If you're both on the same network, your data drops to Layer 1 of your machine, and then possibly through a connection (Layer 1) to a switch (Layer 2). On the switch, the MAC address of the colleague's machine is already included in the table, and the data does not need to go to the router. Instead, it descends to the port and connects directly to the colleague's machine. This is the simplest network setup in real life, as we rarely use a direct physical connection anymore. In this simple setup, you only need to jump to layer 3 if you want to span multiple networks. If you have a virtual network on your chosen cloud provider and then try to connect to another virtual network, you'll need to establish an IP address and open a port to connect over an open internet connection, or use some kind of virtual routing solution, such as Equinix's Fabric Cloud Router to connect across the network.
real life
Hardware in a world outside of OSI abstraction is not so simple. There are Layer 3 switches with shallow routing tables; Ability to handle multi-layer switches up to Layer 4 because they understand MAC addresses, IP addresses, protocols, and ports; Handle Layer 1, 2 and 3 bridge routers; Gateways that can even work at any layer.
It is common to use the OSI model for troubleshooting. Just as developers use tracebacks and breakpoints to discover where code breaks, network engineers use the OSI model to discover where data stops flowing. From finding a closed port to discovering that HTTP works but HTTPS doesn't, the OSI model can provide a checklist to verify that all of your network components are working properly. It's not just for data centers or on-premises networks. You can use the OSI model to troubleshoot the virtual network of a Kubernetes cluster or the port of a Docker container. Virtual networks typically follow many of the same conventions as physical networks, from ports and connections to VLANs (Virtual Local Area Networks) and IP-WAN (Internet Protocol Wide Area Networks).
The TCP/IP model is a more accurate representation of the Internet as we know it, and many consider it to be a more practical learning model. However, many, if not all, networking tools and hardware vendors use the layer naming scheme of the OSI model to refer to features, such as "Layer 2 local networking" or "Layer 3 network connectivity". Cybersecurity vendors may talk about distributed system Layer 3 and Layer 4 attacks. It's important to understand the concepts behind these terms, if just to keep up with the context of the discussion.