Response: The OSI Model Is a Lie
Every now and then I stumble upon a blog post saying “OSI 7-layer model sucks” or “OSI 7-layer model is a lie”, most recent one coming from Robert Graham.
Before going into the details, let’s agree on the fundamentals.
Most everyone who ever tried to build a network spanning more than one transmission technology and including intermediate nodes came to the conclusion that layered approach to networking makes sense.
Whether you have three, four, five, or seven layers in your model doesn’t matter. What really matters is that your model contains all the functionality you need to implement host-to-host networking in target environment.
While the conceptual split of functionality in the OSI 7-layer model makes perfect sense to me, there were few implementations of transport layer or above at the time when it mattered (when it was still unclear whether IP or CLNP would prevail).
Lower layers were well specified and worked well enough that they were considered as a replacement for IP when everyone realized IPv4 was running out of address space. Unfortunately, a clash between IAB and rest of IETF (that nobody wants to talk about) resulted in “let’s start from scratch and build our own stuff”. We’re still dealing with the results of that decision (see also: second system effect).
Finally, reading the The Elements of Networking Style book will give you an idea of the battles between engineers building ARPANET and religious zealots promoting One True Religion (OSI model). I was lucky enough to be a bit too young to be involved in them, and remote enough to have a “let’s use the bits that make sense” perspective, but unfortunately it looks like some people still have battle scars.
However, regardless of what your position might be, PLEASE do not spread the alternative facts. Here are the ones from Robert’s post that triggered this rant:
OSI model never worked and never came to pass
False. There were working implementations of the full stack, and at least the lower three layers were used extensively in DECnet Phase V, SDH management, TUBA trials…
OSI wanted a “connection-oriented network layer”, one that worked like the telephone system, where every switch in between the ends knows about the connection.
While that might have been the message passed around by the religious zealots of both persuasions (see above), OSI model had both connection-oriented and connectionless service at layer-2 (LAN or WAN) and layer-3 (CLNS versus CONS). CONS was based on X.25 and CLNS was similar enough to IP that you could run TCP on it (and there was code in Cisco IOS doing that).
The big standards bodies wanted a slightly different way of how Ethernet should work, with an LLC layer on top of Ethernet. That never came to pass.
The “what is the whole LLC mess” topic deserves a blog post of its own, so I’ll just mention a few facts:
- The standard bodies wanted to have a common top-sublayer of LAN technologies (Ethernet, Token Ring, Token Bus, FDDI) so you could (in theory, with great pains) make them interoperate. LLC was supposed to be that layer;
- Even today Ethernet supports three encapsulation formats: Ethernet-II (Ethertype), LLC, and SNAP (Ethertype in LLC). At least IBM used SNAP encapsulation on Ethernet (to interoperate with Token Ring) and Cisco IOS supported SNAP encapsulation for IP as early as mid-1990s.
Admittedly, with Ethernet being the only remaining LAN technology, LLC makes little sense… but like junk DNA some headers never go away. PPP frame is still mirroring the SDLC frame format with destination address (useless on P2P media) and control byte just in case you’d want to run connection-oriented PPP… which is described in RFC 1663 and was implemented in Cisco IOS (and came really handy in high-BER environments).
There’s no Session or Presentation Layer in modern networks.
What about MP-TCP, HTTP, QUIC, or MIME? They provide some of the functionality that Session or Presentation layers were supposed to implement.
Unfortunately someone in the early ARPANET days decided they don’t need them even though it was evident (as Mike Padlipsky explained in his book) that you need a common presentation format in something as simple as virtual terminals. We’re still paying the price dealing with add-on kludges. At least they managed to reuse the MIME registry in HTTP.
How about ASN.1, XML and JSON? They are all standard ways of encoding data structures (see also this wikipedia article). So don’t tell me there’s no presentation layer in today’s networks.
And finally a personal note to Robert (in case he ever comes across this rant): I love your writing, and I rely on it being technically correct, so please keep it that way.
In case I got you interested, I would highly recommend the The Elements of Networking Style book for its historical perspective, the awesome History of Networking series of podcasts, as well as my How Networks Really Work webinar.
It's funny that every course, every book teaching us networks begins with that famous model, and it's always illustrated with the famous ladder-style picture with headers. You know it, something like that:
Sometimes they understand there is no headers on L1 so they omit it. Sometimes they remember Ethernet and PPP-style protocols has trailers so they add FCS. Sometimes they understand that there are always have doubts where in L5-L7 everything is, so they omit them too.
This concept explains basics of encapsulation and de-encapsulation on example of OSI model, and obviously this ladder-style thing is senseless in 2019. Protocol encapsulations can be much, incredibly much more complicated than just 7 layers. Moreover, they all agree that Ethernet is L2 protocol and IP is L3 protocol, so if we take, for example, MPLS, it should be... L2.5?
Anyway, they all agree that:
* There are layers, numbered from 1 to 7, with some crappy names that must be remembered.
* Each network protocol corresponds (or means to) to a single layer.
* These 7 layers are not enough in 2019, there should be more layers to represent modern protocols
* Some of these layers are obsolete and not used in modern world
* Notable layers are 2 for Ethernet, 3 for IP, and 4 for TCP
----- NOW FUNNY THINGS START -----
Only a few people in the world know *what is* that model actually. It's specified in ISO/IEC 7498, publicly available on ISO website, and almost nobody ever tried to read it.
In the list above only one thing is true: it's actually 7 layers in this model. All the rest claims are false.
* The OSI model in ISO/IEC 7498-1 : 1994(E) DOES NOT specify layers for PROTOCOLS.
1.18 This Reference Model does not specify services and protocols for OSI. It is neither an implementation specification for systems, nor a basis for appraising the conformance of implementations.
* It's network FUNCTIONS what corresponds to layers in OSI model. Layers are organized in that way that they are mutually exclusive and collectively exhaustive, so 7 is enough for any possible network function. Boundaries between layers help to determine to which layer a single network function belongs to.
* PROTOCOLS don't correspond to layers in OSI model.
* Modern (and not so modern) protocols often implement FUNCTIONS that correspond to different layers.
For example, modern switched Ethernet implements L1, L2 and L3 functions:
- it specifies a communication path in the physical media among two or more physical entities, that's L1 function per 7.7.2
- it specifies data-link connection that is built on top of physical connection, that's L2 function per 18.104.22.168
- it specifies the relaying of data across different physical links, and that's L3 function per 22.214.171.124
And TCP actually does not only L4 tasks like multiplexing data, it actually creates sessions (L5), and selects use of session-services by using TCP options (L6).
Please don't confuse OSI model with OSI protocols stack, that's a whole another story.
I would be happy to hear your objections and additions, accompanied with cites from the standard. Moreover, Ivan, if you would like to tell the truth to the world, I'd gladly assist you with that.
"126.96.36.199. For information to be exchanged between two or more (N+1) entities, an association is established between them in N-layer using N-protocol"
This one would directly imply protocol(s) at each layer.
Clause 188.8.131.52 and figure 9 when applied recursively results in exactly the stack of headers you drew above, although the wording allows headers or trailers (or anything else).
And finally, "184.108.40.206.1 - Control information and user data are transferred between N-entities in N-PDUs. An N-PDU is a unit of data specified in N-protocol and contains N-protocol-control-information and possibly N-user-data" reads as "every N-PDU must have N-header and may have N+1-data" and while we may be creative again and say "but a null layer would have null headers" the generic interpretation of a stack of seven headers (even if some of them are null) would still be correct.
There are other places in the text requiring strict communication between layers (N+1-layer entities talk through N-layer entities).
I could go on, but I hate retyping text from a scanned paper copy (which is what I got from the ISO web site).
So if nothing else, I completely understand how everyone gets their idea even if the preamble to the standard is vaguer than that.
My point is those N-protocols *by definition* rely on N-functions performed by N-entities. If a protocol specifies a set of rules and formats which determine behavior of entities in the performance of functions in several layers, it is by definition not an N-protocol.
For example, Ethernet is not L2-protocol in this sense, but 802.3 chapters 6-9 are L1-protocol for 10BASE-5 (Figure 8-1, IEEE Std 802.3-2018, p.216), chapters 2-5 are L2-protocol for any Ethernet network (same as above), and 802.1D is L3-protocol for switched Ethernet. The "Ethernet protocol" in modern sense is just a set of N-protocols in terms of OSI model, where each protocol specifies its own N-functions.
> Clause 220.127.116.11 and figure 9 when applied recursively results in exactly the stack of headers you drew above, although the wording allows headers or trailers (or anything else).
Figure 9, indeed, illustrate something very similar to what we see in Wireshark, with sequential headers in order that resemble a common "understanding" of N-protocols in OSI. However, even if we assume that the figure show exactly those blocks of bits and how they're transferred from layer to layer being encapsulated and de-encapsulated, the notes 2 and 3 make all this concept very weak:
* Note 2: This figure DOES NOT imply any positional relationship between protocol-control-information and user-data in protocol-data-unit. // there can be header, footer, or control information can be scrambled into data, or whatever
* Note 3: An (N)-protocol-data-unit may be mapped one-to-one into an (N - l)-service-data-unit, but OTHER RELATIONSHIPS ARE POSSIBLE. // there can be close to zero relationship between what we see on N+1 layer and "payload" (or SDU) on N-layer.
What is even more important, the N-SDU (or N-layer "payload") is not what we see in Wireshark. If we see a typical sniffed Telnet packet, we only see L1-SDU and not L2-L7 PDUs. The L4 PDU is NOT some extracted substring from it, marked as TCP header, it is by definition an entity existing only withing the L4-entities (loosely saying, TCP handlers on end nodes, even though it's not about TCP at all).
When L4-entity processes its L4-SDU (data), it reads necessary service data from it, adds L4-PCI (some memory structure, which in case of TCP is different from what we know as TCP header at least we need to know a socket, not just a port number), generates L4-PDU, then calls L3-handler and transfers its L4-PDU there, while converting the latter to L3-SDU (providing it with necessary L3 service data).
Again, it's not about Telnet, TCP, BSD sockets, Wireshark or any actual implementation of any existing or fictional protocol. It's about network functions that can or cannot be implemented in any particular way. OSI model (as well as DoD one) was created not to be a nice representation of onion-like data structures, but to restrict vendors from implementing something that is impossible to reproduce. Those were attempts to regulate vendors and prohibit them to sell solutions that are incompatible not only between different vendors but often even within a single product line. Before that it was possible to implement a remote shell protocol that only worked on a specific OS on a specific mainframe model over a specific cables. Because it would be very dumb to create a standard that whitelists all possible protocols, both models describe not the protocols but network functions, and they restrict relations between those functions.
> I completely understand how everyone gets their idea
It's easy to think that headers order in a *typical* modern packet represents OSI layering, while to read the standard is almost an impossible thing.
Everyone would benefit if people spent less time venting on social media and more time studying their profession.
TCP/IP (or DoD, if you prefer that) model was created in late 60's, while ISO OSI model was published in 1978. I would say those american guys did awesome job to implement something that became to exist 10 year later.
The Network Associates Guide to Communications Protocols was probably one of the most useful diagrams to me for many years.
The OSI model is a specific implementation of the generic layered services. The standardization was led by the IBM networking solution and the result of a bad political compromise.
For really learning how network layering is actually built in real life, you should read the ITU-T G.805 and G.809 standards. It is a much better framework and the OSI model is just a very specific instance of the real models.
But most networks are actually not following the OSI model. However, with the ITU-T G.800 series you could model every network more precisely.
Getting into the history of what was intended to mean what should be subservient to the idea of what is practical today. If you look at a general packet on wireshark, you can see three headers in front of the data: The TCP or UDP header, the IP header, and the Ethernet header. In practical terms then, there are 4 parts to deal with, and then the idea of the physical medium that the data has to travel to get to the next point.
The OSI model does not map to this idea, just as the original TCP/IP model doesn't. A 5 layer model that acknowledges TCP/UDP, IPv4/IPv6 and maybe even Ethernet as the standards that they are is what we should be focusing on using so that we can stop having these stupid arguments. The OSI model has absolutely no practical value except as a historical reference, and even that need is dubious.
> Getting into the history of what was intended to mean what should be subservient to the idea of what is practical today.
... and brings us RFC 1025 rules 4 and 11. Or, as someone much smarter than me once said...
> Those who cannot remember the past are condemned to repeat it.
It's always worth understanding how things should work, and why they deviated from that ideal... but I completely understand that if you're focused on troubleshooting daily brokenness with Wireshark, then all this sounds completely academic.
Unfortunately, it also sounds academic to most people designing "disruptive" virtual networking solutions, and so we end with a spaghetti mess of software-defined NAT and static routes.
I believe you are making the same point as me then Ivan.
The reality of a packet is not understood and instead weird academic bloat ideas are making their way into real software and creating a weirdly complex mishmash of spaghetti code justified by people pointing to "standards" like OSI for their reasoning.
Teaching people the simplified reality that packets are just headers with a purpose is what we should be doing. The history is interesting from a historical perspective, but these horses have been beaten to dust and the rest of the world is driving cars now.