What network models are for

Think of a reference model like an architectural blueprint for a building. The blueprint does not build the 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 data formatting, encryption, and compression. Think: "Is this JSON or XML? Is it encrypted with TLS?"

Layer 5, Session. Manages ongoing conversations between two systems. Example: keeping a WebSocket connection alive so messages flow both ways.

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 (the hardware addresses burned into your network card) operate here. 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 shows why each layer exists. Click or tap any layer to see what it does and which real protocols operate there.

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.

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.