Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

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.

More Information

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.

Please read our Blog Commenting Policy before writing a comment.

7 comments:

  1. There is a huge lie on OSI model. Or misunderstanding. Or a lie. I prefer to think it's a worldwide lie, and I explain here why.

    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:

    Data
    L7|Data
    L6|L7|Data
    L5|L6|L7|Data
    L4|L5|L6|L7|Data
    L3|L4|L5|L6|L7|Data
    L2|L3|L4|L5|L6|L7|Data
    L1|L2|L3|L4|L5|L6|L7|Data

    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 7.6.2.1
    - it specifies the relaying of data across different physical links, and that's L3 function per 7.5.2.1

    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.

    ReplyDelete
    Replies
    1. Thanks for the extensive comment. While I might agree that a creative reading of ISO/IEC 7498-1 might result in your perspective (and I was always fond of creative reading), there are numerous detailed provisions in the standard that would make most people converge on the standard interpretation. For example:

      "5.3.2.1. 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 5.6.2.1 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, "5.8.8.1.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.

      Delete
    2. Well, it's clear that "N-protocol" term exists in the standard, as it is specified as "A set of rules and formats (semantic and syntactic) which determines the communication behavior of (N)-entities in the performance of (N)-functions."

      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 5.6.2.1 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.

      Delete
  2. Almost nobody has read the ISO draft. People just assume what they've heard about the OSI model is true. That's how we get silly ideas like "ARP is layer 2" or "OSPF is layer 3" when they're both actually layer 7 application protocols. And the TCP/IP vs OSI dichotomy is nonsense. TCP/IP is just an implementation of OSI.

    Everyone would benefit if people spent less time venting on social media and more time studying their profession.

    ReplyDelete
    Replies
    1. ... or you could say that ARP is N-protocol-control-information for IP ;)... but of course I agree that OSPF is an application with its own transport layer (LSA flooding and retransmissions), session layer (hello exchanges) and presentation layer (OSPF packet format).

      Delete
    2. > TCP/IP is just an implementation of OSI.

      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.

      Delete
  3. I found the OSI model most useful to understand all how all the different protocol stacks related to each other. This was important if you had multiple protocol stacks running on the same network, and/or you were going from one customer to another and troubleshooting different stacks at each customer.

    The Network Associates Guide to Communications Protocols was probably one of the most useful diagrams to me for many years.
    https://sebsauvage.net/comprendre/tcpip/protocols.pdf

    ReplyDelete

Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.

Sidebar