The OSI Model

Introduction

#

When it comes to networking, one of the terms that gets thrown around super often is the OSI model. But what is the OSI model? Well, the OSI (Open Systems Interconnection) model refers to the theoretical model for the internet put together by the ISO (International Organization for Standardization). It is an attempt to categorize how networks should work, from what end users see all the way to the wires the communication is happening on. Unfortunately, it happened far and away from when and where networks were actually being built. Hence why we’ve got the TCP/IP model, which more closely represents how networks in the real world work. Then why learn the OSI model? As it turns out, the OSI model being a formal declaration makes it really easy to standardize and build coursework around.

But enough about what the OSI model is. What are the layers of the OSI model? Well, they can be defined with a simple moniker: “All People Studying This Need Drastic Psychotherapy”. Let’s get into some more detail.

Layers

#

Physical

#

When building a network, you need to eventually send signals from one device to another. The physical layer refers to the actual medium of transfer of that signal, be it over a wire or over a wireless transmitter. Typically, work on this layer focuses on defining what a signal looks like. For example, layer 1 answers what voltages on a wire are used for a 1 or a zero, or what wave length is used for wireless transmission.

Data link

#

Once you have a way to send signals, a physical connection between devices, you have to have some way to actually know what device you need to talk to. A future post will likely cover some different topologies that can be used for communication on this layer, but it will suffice for now to say that devices on this layer are identified by their MAC (Medium Access Control) address.

Network

#

Now that we’ve got the ability to identify devices on the physical level, let’s talk about limitations. MAC addresses have a limited length, and thus a limited number of unique devices. Even fewer when we account for the fact that large portions of the available addresses are reserved for identifying a device’s manufacturer by convention. This means that there is a likelihood that on the internet, many devices share MAC addresses. And yet the internet continues to function. Why is that?

Enter the Network layer: an abstraction that allows us to help avoid conflicts from duplicate MAC addresses by creating logical networks instead of physical networks. To say it another way, if you were in a room, and 2 people had the name Steve, you’d probably need some way to identify which “Steve” you were talking to. So you’d come up with some sort of logical rule, such as last name, and use that to identify an individual instead. This is the exact same thing that we do with the internet and MAC addresses. Only instead of asking our friend Steve to go by his last name, we ask him to move into another room. Two Steves still exist, but now you can just refer to both as Steve since they exist in different rooms (different networks).

Transport

#

Now that devices can communicate over a network, let’s talk about services. When you interact with a website, that server could be running more than just the website service. It could be running a database service at the same time. What if the end application, your web browser, needs to interact with both of those at once. But with the network level, I can only communicate with one service at a time, unless there is an additional abstraction that allows you to do that. Enter ports. Ports allow us to solve that more than one service at once problem.

Session

#

Now that we have the ability to identify services, let’s talk about the fact that services are by default stateless. This works great for things like DNS, or perhaps running a single query to a database. These are services that don’t require any data other than the initial input. You send 1 question, you get 1 response. But the modern internet is just a bit more complicated than asking a single question. We have complex data flows, logins spanning multiple devices, and real-time communication over the internet. These use-cases utilize the session layer to be able to function.

Presentation

#

Any good application needs to be able to display data to users. But how do you do that? Well, the presentation seeks to answer this question. This is the land of json, HTML, markdown XML, maybe a bit of raw binary, and a variety of other standards of sending data. Put simply, the presentation layer is all about sending data, and figuring out how to structure it.

Application

#

Data on the presentation layer is really only meant to be read by machines. Take a table in HTML for example:

 <table>
  <tr>
    <th>Company</th>
    <th>Contact</th>
    <th>Country</th>
  </tr>
  <tr>
    <td>Alfreds Futterkiste</td>
    <td>Maria Anders</td>
    <td>Germany</td>
  </tr>
  <tr>
    <td>Centro comercial Moctezuma</td>
    <td>Francisco Chang</td>
    <td>Mexico</td>
  </tr>
</table> 

That is pretty unreadable to a human. Luckily, at the application layer, the machine-readable stuff can be interpreted. That is the job of the application layer, to turn the stuff at the presentation layer into something that looks readable to us mere mortals, something like this:

Conclusion

#

If you didn’t notice, I kind of breezed through the session, presentation, and application layers. This was intentional, as the line between the three isn’t always neatly dilineated. For services like DNS, there’s almost nothing ever presented to the end user about the data, and yet they constantly interact with it behind the scenes through other applications that aren’t ever presenting the info to the end user. So the line gets a bit blurry. This blurriness is why people often just use the TCP/IP model, since it describes networks in practice, unlike the theory provided by the OSI model, which combines these three layers into just one application layer. It doesn’t really matter how or what interactions are taking place so long as the data is there.

As always it was great to write about a basic concept, and I can’t wait to see what I feel like writing about next. Remember, you can do hard things. This is TheITFirefly – Signing Off.