What network models are for

Think of a reference model like an architectural blueprint for a building. The blueprint does not buildthe building. It gives every contractor (electricians, plumbers, structural engineers) a shared plan so they can work independently without breaking each other's work.

A network reference model works the same way. It splits communication into layers, where each layer has one job. The layer that moves electrical signals along a cable does not need to know about web browsers. The layer that handles web requests does not need to worry about voltage levels on the wire.

Before ISO published the OSI model in 1984, every major vendor (IBM, DEC, Honeywell) had its own proprietary networking system. If you learned IBM's SNA, that knowledge was useless when you sat down in front of DEC's DECnet. There was no shared vocabulary for asking "which part of the communication broke?"

Hubert Zimmermann, the original architect, published six principles for deciding where one layer should end and the next should begin. He wrote these in a 1980 IEEE paper, four years before the model was formally published:

Each layer in the OSI model has a specific responsibility. Data starts at the top (Application layer, where a user clicks "send") and moves down through each layer, picking up headers along the way. On the receiving end, the process reverses. Each layer strips its header and passes the data up.

Here is a quick summary. We will cover each layer in more detail in Module 1.4.

Layer 7, Application. Where software talks to the network. Your browser, email client, or API call lives here. Protocols: HTTP, SMTP, DNS.

Layer 6, Presentation. Handles how data is represented for the application: character encoding, serialisation formats, and cryptographic presentation of data. In the Internet stack these functions are normally implemented by application libraries and protocols rather than by a separate deployed layer.

Layer 5, Session. Describes dialogue management, checkpoints, recovery, and long-lived conversations. Modern systems still need those functions, but HTTP cookies, WebSocket connections, RPC frameworks, and application state usually implement them.

Layer 4, Transport. Responsible for reliable delivery between two endpoints. TCP guarantees delivery and ordering. UDP skips those guarantees for speed.

Layer 3, Network. Handles addressing and routing across networks. IP addresses live here. Routers operate at this layer, deciding which path a packet takes.

Layer 2, Data Link. Moves data between devices on the same local network segment. MAC addresses operate here as local link identifiers. They are often assigned by the network interface vendor, but modern operating systems can change or randomise them. Switches work at this layer.

Layer 1, Physical. The actual electrical signals, light pulses, or radio waves on the wire, fibre, or air. Cables, connectors, and voltage levels.

The diagram below names each layer with its single responsibility and one real-world protocol that operates there. Layer 4 Transport is marked because that is the layer most live troubleshooting starts with: if the transport never connects, nothing above it can run.

OSI defines seven layers. The Internet (TCP/IP) uses four. People sometimes treat these as rivals, but they describe the same underlying communication at different levels of detail.

OSI came from a standards body (ISO) trying to create a universal framework. TCP/IP came from researchers (DARPA) building a working network. OSI won the vocabulary. TCP/IP won the deployment. Both survived because they do different jobs.

When you troubleshoot a live system, you typically use the four-layer Internet model because it matches how protocols are actually implemented. When you need to describe a responsibility precisely ("this is a transport-layer function"), OSI vocabulary is more specific.

The map below shows how the two models line up. The TCP/IP Application layer absorbs three OSI layers; the TCP/IP Link layer absorbs two; Transport and Network map across one-to-one.

Good engineers use both depending on context, the same way a builder might use metric drawings for structural work and imperial for plumbing fittings. Knowing when to use which model matters more than memorising either one.

On August 30, 2020, CenturyLink (now Lumen Technologies) had a five-hour outage that took down Amazon, Twitter, Microsoft, Cloudflare, Reddit, Hulu, and Discord.

The root cause was one badly written Flowspec rule. Flowspec is a BGP extension that lets engineers distribute firewall rules across a network using the same protocol that handles routing (BGP, or Border Gateway Protocol, the system that tells routers how to reach different networks).

The rule was too broad. It matched BGP traffic itself. So every router that received the rule immediately blocked its own BGP connections. When BGP dropped, the routers stopped receiving the bad rule, so BGP came back. When BGP restored, the rule propagated again, and BGP dropped again. A persistent on-off loop across the entire network.

Users saw websites go unreachable (Layer 7). The actual problem was a routing configuration at Layer 3 destroying the protocol that carried it. Without understanding the layer separation, the oscillating pattern makes no sense. With it, the explanation is straightforward: a Layer 3 control-plane function was carrying a rule that killed Layer 3 itself.

When a service fails, resist the urge to guess. Instead, identify the first communication function that stopped working.

A web request goes through these steps, in order:

1. The browser asks DNS for an IP address.
2. The operating system opens a TCP connection to that IP address.
3. TLS negotiates encryption (for HTTPS sites).
4. HTTP sends the actual request and receives a response.

Each step depends on the one before it. If DNS fails, nothing else can happen. If TCP connects but TLS fails, you know the problem is between Layer 4 and Layer 6.

Start at the top (can you resolve the domain name?) and work down. The first function that fails is where your investigation begins.

Compare these two statements from the same incident:

"The website is down."

"DNS resolution for this domain returns SERVFAIL from three different resolvers, which suggests the authoritative nameserver is unreachable."

Both people noticed the same symptom. Only the second person told you something you can act on. That is what a model gives you.