The OSI Model Revisited

About this article

In this article I discuss the OSI model, and how as a conceptual model for interconnectivity it is relevant to various technology disciplines. I also discuss the shortcomings of existing reference materials, and I provide a more practical reference point for the engineering, configuration, and troubleshooting of system interconnectivity.

Having a background in engineering web applications, the article and associated diagrams focus on HTTP communication, and how it relates to the OSI model layers. HTTP is a ubiquitous technology, so it's the perfect candidate to illustrate the model in a more practical fashion.

Due to the depth of this subject, it's difficult to cover within any single article. This article focuses on how the model and linked diagrams can be an asset for technology professionals, with the diagrams assessing the model layers from a logical and physical perspective. Within the diagrams I have deliberately pushed the limits of content inclusion, in order to delineate key aspects.

Given the broad scope of the OSI model, this article is relevant to students, software engineers, network engineers, system admins, operations and support staff, change managers, incident managers, and anyone interested in how system interconnectivity is generally achieved.

What is the OSI model?

OSI stands for Open Systems Interconnection, with development of the OSI model starting in 1977. The model was designed to address the problem of incompatible proprietary network architectures, that had evolved in the 1960's and 70's. The model describes the layers of a computing system that, as a whole, enable software applications to communicate across separate host systems. Whether this be two PCs on a local network, a smart phone and API over the internet, software as a service (SaaS), or any number of interconnected applications.

The International Organization for Standardization (ISO) developed the conceptual OSI model, as well as a set of accompanying protocols intended to guide implementations. Due to the complexity of these protocols, many failed to be adopted over simpler alternatives. Due to this, the model is considered as irrelevant in some circles.

The conceptual model however, is still relevant to this day. It partitions the concerns of systems interconnectivity into 7 distinct layers, describing the unique responsibilities that each layer must implement. Even though clear layer boundaries may not be adhered to within certain implementations, the concerns of each layer are appropriately addressed within modern computer systems. In place of the formal OSI protocols that failed to gain traction, are other standards and protocols such as HTTP, DNS, TCP, and IP, providing the primary link between the conceptual model and logical solutions.

The 7 layers of the OSI model are listed below. The upper layers are typically the focus of application engineers and software development frameworks, with all lower level functions typically provided by operating system components, network device drivers, and network adapters.

In addition to the OSI model, the alternate TCP/IP model presents a more simplified representation of system layers. The TCP/IP model is generally preferred by network engineers and other professionals focused on the network and transport layers. This alternate model groups the top 3 OSI layers together, as well as the bottom 2 layers. Unfortunately this somewhat disregards the concerns of engineers focussed on these layers.

The OSI model presents each layer as being a sequential stage for interconnectivity, masking the concerns of adjacent layers. In practice this is not always the case, and communication between the layers is not always linear (particularly with regards to presentation and transport). This is not something usually discussed within articles describing the OSI model, and caveats such as this, along with other ambiguous descriptions, often result in more questions than answers.

The failure of traditional resources to relate the OSI model to logical and physical implementations, has resulted in the model being an underutilized reference point within several technology disciplines.

How is the OSI model still relevant?

The conceptual foundations defined by the OSI model, continue to underpin the internet and modern applications. Even so, traditional resources only serve as an introduction for students, or as a general guide when discussing communication protocols and technologies.

Outside the scope of these typical contexts, the OSI model has failed to reach its full potential as a method for clarifying systems interconnectivity. The reasons for this are discussed further below, but first let's consider the model's continued relevance to various technology professionals:

• Application Engineers: The top 2 model layers have the most relevance for application engineers. That said, a basic understanding of the concepts and technologies at the middle layers is beneficial, when seeking the root cause of connection issues.
• Network Engineers: For network engineers the middle 3 layers are the most relevant. The protocols and standards at these layers are essential for engineers configuring routers, firewalls, load balancers, and proxy servers in a corporate setting. Some knowledge of the upper layers is also essential.
• Operations Staff & System Admins: Knowledge of the concepts and technologies at the upper and middle OSI layers, may lead to valuable insights for operations staff and system admins, supporting applications or network services.
• Change Managers & Incident Managers: An overview of the model and its relationship to certain technologies, may help drive discussions and actions with application and network engineers. Particularly when overseeing connectivity changes or incidents within complex application ecosystems and networks.
• Security Engineers & Penetration Testers: A broad understanding of the model and the products targeting the middle and upper layers, can enable security professionals to map and further classify CVE vulnerabilities and exploits associated with interconnectivity.
• Enterprise Architects: Mapping various tools and products to OSI layers, can present a unified view of the interconnectivity solutions applied within/available to technology departments.

These examples - from the viewpoint of technology teams in medium to large organizations - say nothing of the vendors and engineers concerned with developing operating systems, network management software, physical network devices, and device drivers. Further disciplines such as these are illustrated in the diagram below.

Given the relevance of the OSI model and the benefits discussed above, let's explore why it's an underutilized reference point for technology teams:

Why revisit the OSI model?

The continued relevance of the OSI model and the lack of practical reference materials, present a fantastic opportunity to revisit the model.

Given the complexity of systems interconnectivity, no high level model will ever map perfectly to every possible implementation. This holds true for the OSI model. Even though the unique concerns outlined within each layer are catered for within modern systems, the logical implementations of these layers is not always clear cut. The dynamic library files and drivers provided by operating systems and third party vendors may blend code for multiple layers into a single file (as is the case with Windows TCP/IP drivers). Development frameworks used by application engineers may also combine logic for the presentation and application layers into a single module.

That is not to say that the OSI model layers are irrelevant, or that they can't be compared to actual system implementations. Just that it takes effort to relate the conceptual and logical aspects of system interconnectivity, and that certain caveats must be acknowledged. What good are conceptual models after all, if we can't relate them to logical implementations at some point? The same question can also be asked of physical implementations, and the types of devices or dedicated servers that target particular OSI model layers.

It's notable that for a model describing systems interconnectivity, there are very few illustrations relating the model to multi-system implementations. That said, this is a difficult endeavour, given the range of technologies and solutions available. The internet and corporate networks can be as complex as any logic running on a CPU, and illustrating the OSI model in these physical contexts requires focused examples, and careful consideration.

In order to better cover this subject, and provide a clearer link between the OSI model and actual implementations, I've produced both a Single System diagram, and a Multi System diagram. Due to the breadth of this topic, the diagrams focus primarily on HTTP driven connectivity and communications, and the technologies that typically underpin these. Various responsibilities and protocols are discussed, as well as the general flow of data through the model's layers. The diagrams also illustrate the difficulty of relating the OSI model to logical solutions, with certain logical components crossing conceptual layer boundaries.

These diagrams present an informal yet edifying way, of mapping logical and physical architectures to the OSI model. While it's difficult to fully align OSI layers with products and technologies, the goal here isn't a perfect classification, but rather a more enlightening viewpoint. Mapping the connectivity waypoints of systems in this fashion, can further aid the people engineering and supporting such systems.

In Practice

As demonstrated within the attached diagrams, the OSI model can be used to visualize the technologies underpinning application ecosystems. It can also be used to shine a light on potential knowledge gaps, ownership gaps, and points of disconnect within technology departments. Such gaps aren't always obvious, and it often takes an incident to highlight this to product owners and stakeholders.

For example, there are often areas where application and network engineers have a misaligned understanding, such as appropriate monitoring and handling of grey failures. The intricacies of certain protocols and products might also evade both types of engineers, particularly if they've never encountered certain edge cases.

I've faced multiple challenges in this regard, during various projects and incidents:

1. Reconciling HTTPS protocol and cipher versions employed by client operating systems, client applications, load balancers, server operating systems, development frameworks, and bespoke server applications.
2. Reverse engineering HTTP request rewrites within disparate layer 7 devices, only to find that further undocumented rewrites were occurring within proxy servers.
3. Discovering a load balancer vip closing TCP connections after each HTTP request, when those same TCP connections were used as a means to track sticky sessions (back end server persistence).
4. Basic TCP health checks indicating that a server was 'up', when HTTP health checks would have shown failures, if had they been implemented.
5. Troubleshooting intermittent proxy connectivity issues affecting bespoke applications, only to eventually discover a development framework bug was the root cause.
6. Assisting app teams troubleshooting intermittent connectivity issues, discovering that they had only arranged firewall rules for a single node tied to a Global Server Load Balancer (GSLB).
7. Determining how requests to the same IP address are automatically routed to a new physical location, when migrating to a new load balancer solution.

In many of these situations I've found conflicting assumptions, knowledge gaps, or ownership gaps, between software and network engineers. Adding to these challenges is usually a lack of designs and documentation (even a minimal level).

It is in these instances that I've found myself drawing system and network architectures by hand, tying together known technologies and settings, stack traces, error logs, network dependencies, software specifications, and varying layers of the OSI model. All of this in an attempt to see past the visible interfaces and integration points, and to lift the lid of underlying implementations.

While it's clear that no single diagram can fully describe interconnectivity in a complex system or network setting, sometimes a more elaborate reference point is all that is required to trigger new avenues of thought. Had the Single and Multi System diagrams below been available to me in years gone by, some of the engineering challenges that I faced would have been much less arduous.

The Diagrams

Please see the Single System HTTP Example and Multi System HTTP Example diagrams linked below.

Within these diagrams I've aimed for a practical overview of the OSI model, focussing on the HTTP protocol and its dependencies. There are however many protocols related to each OSI layer that are deliberately excluded.

The diagrams discuss the request, segment, and packet transfer units for HTTP, TCP and IP protocols, as well as the associated 'headers' for each. I've not illustrated or described the purpose of these headers and their relationship to the 'payload' of these protocol transfer units, but there are many online resources explaining these.

The Single System diagram focuses on the Windows subsystems utilised by a web browser for a HTTP request. Windows provides more than one API for connectivity purposes, and browser implementations can also vary per vendor. I've deliberately avoided reverse engineering any browsers for the sake of simplicity (and time).

Within the Single System diagram I've made a somewhat contentious decision, to include components such as Winsock within the transport layer. Some purists may argue that 'sockets' and Winsock are concepts that exist above the transport layer, or at the layer's upper edge, or outside the model completely. While Winsock and other sockets APIs may not perfectly align with the transport layer definition, they build directly upon transport layer capabilities, and operate very closely to this layer. It is for that reason I've depicted Winsock here.

A similar observation can be made of the Windows Filtering Platform components, such as the Base and Kernel Filtering Engines included within the Single System diagram. These components may not be concerned with how interconnectivity is achieved, but they are very much concerned with what is being transmitted via the associated layers, and where.

Within the Multi System diagram I've attempted to cover various devices, configurations, and concerns. Again here I have focussed on HTTP driven interconnectivity, and the typical protocols and solutions that support this. As noted within the Single System diagram, there is ambiguity associated with some technology terms such as 'session'. The term 'gateway' is another, and the diagram briefly illustrates two different types of gateway (API and network). It's worth noting that 'router' and 'firewall' can also be confusing terms, given that home routers typically contain an internal firewall and also act as a network gateway (just as a PC or web server may have its own internal firewall).

In the article I mention how interaction between the OSI layers is not always linear. This is discussed further within the Multi System diagram and the presentation layer description. Here I point out how encryption is classed as a presentation layer concern, yet for HTTPS, encryption actually occurs after a message is first fragmented by the TLS record protocol, which sits at the lower transport layer (with HTTP over TCP). Some applications are also void of session layer logic.

The rapid rise of HTTP/3 should be noted. Unlike HTTP versions 1.1 and 2 before it, transport for HTTP version 3 is not based upon the TCP protocol. HTTP/3 replaces TCP with the UDP based QUIC protocol, and this is a fundamental shift for HTTP. While web browsers have been quick to support HTTP/3, the uptake within non-browser based applications will be slower. Newer versions of software development frameworks must be utilised for QUIC protocol support, forcing engineering teams to upgrade and re-test their applications against relevant interconnectivity endpoints.

A Final Note

This article and the associated diagrams are not a panacea, but hopefully they help bridge the gap between the conceptual, logical, and physical facets of systems interconnectivity.

The attached diagrams are free to redistribute, so long as the original authorship details are retained. Where possible, a link back to this blog would also be appreciated. Suggestions and corrections are welcome, and I shall consider these for inclusion in future iterations.

Thank you for visiting my blog.