On the Usability of OSI Layered Networking Model
Two weeks ago I replied to a battle-scar reaction to 7-layer OSI model, this time I’ll address a much more nuanced view from Russ White. Please read his article first (as always, it’s well worth reading) and when you come back we’ll focus on this claim:
The OSI Model does not accurately describe networks.
Like with any tool in your toolbox, you can view the 7-layer OSI model in a number of ways. In the case of OSI model, it can be used:
- As a framework describing what functionality needs to be present in an end-to-end networking solution;
- As a recipe on how to build a networking stack;
- As a particular implementation of that recipe including LLC on Ethernet, CLNP on network layer, TP4 on transport layer…
- As the one true religion
- As a religious tool used to squash the infidels (= the ARPANET folks).
I always viewed OSI model as a framework. As I explained in The Importance of Networking Layers part of How Networks Really Work webinar, you have to implement at least these functions in an end-to-end networking stack:
Trying to implement all that functionality in a large bowl of spaghetti-with-meatballs approach results in a nightmare. It’s much better to have an architecture where every layer in the architecture provides services to the layer above it while consuming services from the layer below it.
Having such an architecture allows you to group the functionality that needs to be implemented in manageable chunks. It also allows you to think about the optimal position of a particular function. For example, do you implement reliable transport on every hop, or do you use an end-to-end reliable transport protocol, or do you do a hybrid of both. As you probably know by now, there is no right answer. In this particular case, the best answer depends on the error rate of the underlying transmission medium.
From this perspective, I would view the OSI model (or an alternative, but I haven’t seen one yet) as an indispensable high-level tool for anyone who tries to understand how networking works.
Unfortunately most critiques of the OSI model come from people who were either exposed to it when it was used as a religious tool, or from people who were exposed to the particular implementation I described above (or its connection-oriented alternative using CONS/X.25 instead of CNLP and TP0 instead of TP4).
Even that implementation wasn’t as bad as the critics would have you believe. It gave us IS-IS (probably the most versatile IGP out there) as well as concepts like “per-host addressing” instead of “per-interface addressing” that would nicely solve a number of stupidities we have to deal with today. Not surprisingly, we’re reinventing that particular wheel with layer-3-only forwarding and IPv6 prefixes assigned to container hosts.
However, there is one serious omission in the OSI model (and I guess Russ and myself are in perfect agreement on this one) - the lack of recursive network layer, resulting in angels-dancing-on-a-pin discussions of whether MPLS is tunneling or not.
Internet Protocol (IP) was always designed to run across another subnetwork protocol (remember: the whole ARPANET was such a subnetwork), and that distinctive characteristic got lost in translation when someone collected various proven ideas and presented them as one-and-only solution (now I’m getting sarcastic, but you should be used to it by now). Some people never stopped explaining that but as always nobody was listening, because everyone knew the right answer… and left us the mess we still have to deal with decades later.
Can we change the fundamental architecture of the Internet? Probably not. Can we make it perform better? Sure… and we can start by understanding the characteristics and limitations of current networking technologies - something I’m trying to explain in How Networks Really Work webinar. So far I got through fallacies of distributed computing, the challenges you have to solve no matter what, and the importance of a layered model of networking. More to come in late October 2019.
Of course it doesn't, neither accurately or not. As per 1.18, the Reference Model does not specify services and protocols of OSI, and it is neither an implementation specification for systems, nor a basis for appraising the conformance of implementations.
It is - as per 1.4 - a conceptual and functional framework which allows experts to work productively and independently (!) on the development of standards. It does accurately describe network functions/services and their relations, and a single application can implement/use multiple services from multiple different layers.
> a framework describing what functionality needs to be present in an end-to-end networking solution
Exactly, Clause 7 describes this functionality and groups specific functions to corresponding layers.
This toy was made for application developers, not for network engineers. Back in the 80's almost every network engineer was actually a developer, and the model helped them to develop a healthy ecosystem of protocols, but today it's rather counterproductive to tell every network kiddie how to build your own network protocol. Windows admins (generally) don't know what is Von Neumann architecture, why do Cisco guys have to study OSI model?
It's like telling the car designers to ignore the air drag ;) or rocket scientists to ignore gravity ;))
The real networks contain a lot of transport layers on top of each other, that the OSI model cannot capture well. There are a lot of other possible function allocations, too.
The proper models are described in ITU-T G.805 and G.809. If someone really want to understand real networks, than he should use the models in those standards.
There is also a mapping with the OSI model, but it is not really necessary...