At the end of the previous module we drew a picture with four protocol families — application, transport, network and data link — and discovered that the picture was, almost literally, a layered model. In this lesson we meet the formal, complete version of that idea: the OSI model (Open Systems Interconnection), a seven-layer reference framework the industry has used for decades to name, organize and diagnose everything that happens on a network. Understanding the OSI model matters for a very practical reason: it is the common language of the profession. When a technician says "that's a layer 3 problem" or a job posting asks for "layer 2 knowledge", they are using this model. By the end of the lesson you will know exactly what OSI is, what each of its seven layers does, and how to use it as a thinking tool.

1. What a reference model is (and what it is not)
2. Origins of the OSI model
3. The seven layers: overview and mnemonic
4. How the model works: two principles
5. Encapsulation and PDUs: the formal names
6. Guided tour: Marta's request through the 7 layers
7. OSI as a diagnostic language

Let's start by clearing up the most common misunderstanding: the OSI model is not software, not a protocol, and not something you install or configure. There is no "OSI program" running on the Valencia router. The OSI model is a conceptual map: an agreed-upon way of splitting the giant problem of "making two computers communicate" into seven smaller problems, each with a name and a number.

A good analogy is a city's subway map. The map is not the city: the distances aren't real and the lines aren't actually straight. But it is enormously useful, because everyone reads it the same way and it lets you say "change trains at line 3" without ambiguity. The OSI model plays that same role for networks.

A reference model is good for:

• Dividing complexity: each layer solves one concrete, well-bounded problem, and can be designed (and studied) on its own.
• Standardizing the vocabulary: "frame", "packet", "segment" or "layer 3" mean the same thing to a technician in Valencia, in Bilbao or in Tokyo.
• Enabling interoperability: if a vendor respects the boundaries between layers, its equipment can work with equipment from other vendors. Meridiano's switch is one brand and its router another, and they get along just fine.
• Locating faults: if you know which layer something is failing at, you know what to check and what to rule out. This is the benefit you will exploit most as a professional.

What a reference model does not do: it does not force real software to be organized exactly that way. As we will see in module 4, the Internet runs on a protocol stack (TCP/IP) that doesn't fit the seven layers down to the millimeter. Even so, the OSI vocabulary is still used to describe that stack. It is the map, not the territory.

In the late 1970s, every computer manufacturer had its own network architecture, proprietary and incompatible with everyone else's: IBM machines spoke SNA, DEC machines spoke DECnet, and connecting equipment from different brands ranged from difficult to impossible. It was as if each brand of telephone could only call phones of its own brand.

To fix this, the ISO (International Organization for Standardization, the same organization behind the ISO quality standards) launched a project to interconnect "open systems" — open in the sense of non-proprietary. The result was published as a standard in 1984: the OSI reference model, with its seven layers.

There is a historical irony worth knowing: alongside the model, ISO also defined a family of OSI protocols meant to implement it... and those protocols lost to TCP/IP, which was simpler, more pragmatic and already working in practice. The Internet does not run on OSI protocols. Nevertheless, the model — the seven-layer map, its names and its numbers — survived and became the universal reference for teaching, documenting and diagnosing networks. The protocols died; the vocabulary won.

Here are the seven layers, numbered from the bottom (closest to the wire) upward (closest to the user):

To memorize the order there are classic mnemonics. The classic one from layer 1 to layer 7:

"Please Do Not Throw Sausage Pizza Away" (Physical, Data Link, Network, Transport, Session, Presentation, Application)

And the equally famous one from 7 down to 1: "All People Seem To Need Data Processing" (Application, Presentation, Session, Transport, Network, Data Link, Physical).

The following table is the heart of this lesson and of the entire module. Notice that the examples column is full of old friends from module 2:

Notice two things:

• Layers 1 through 4 have very concrete data units and devices: they are the "plumbing layers", and they match the module 2 families almost one to one.
• Layers 5 through 7 have no addresses or devices of their own: they live inside software. In module 2 we treated them all together as "application"; OSI splits them into three, and in lessons 03-06 through 03-08 we will see why it distinguishes them and why in practice they tend to merge.

The OSI model rests on two principles worth understanding well, because they explain everything else.

Each layer offers services to the layer above it and consumes the services of the layer below, without needing to know how the others work inside:

• The transport layer (4) tells the application (7-5): "give me your data and I guarantee it reaches the right process at the other end". To pull it off, it uses the network layer (3): "carry this segment to IP 192.168.20.5".
• The network layer (3) uses the data link layer (2): "hand this packet to the next hop on this local network".
• The data link layer (2) uses the physical layer (1): "turn this frame into signals and put it on the wire".

This independence is what allows one layer to change without touching the rest. When Meridiano replaced part of the Valencia cabling with Wi-Fi for the laptops, it changed layers 1 and 2 on those machines (from wired Ethernet to 802.11 over radio), but nothing in layers 3 through 7 had to be modified: the intranet kept working exactly the same, with the same IPs, the same TCP and the same HTTP.

Each layer on the sender "converses" logically with the same layer on the receiver. The TCP on Marta's PC talks to the TCP on the server (sequence numbers, ACKs...); Marta's IP talks to the server's IP (TTL, addresses...); Marta's Ethernet, to the switch's Ethernet. Each layer reads and understands its own header, the one its peer layer put on at the other end, and treats everything else as opaque payload.

It is like one company sending a contract to another: the lawyer writes for the other company's lawyer, the clerk prepares the envelope for the receiving clerk, and the courier deals with the courier. The lawyer doesn't need to know which van the envelope traveled in; the courier doesn't need to understand the contract.

The only real communication happens at the physical layer; all the others are logical conversations carried by the layers below.

In module 2 we saw encapsulation as "putting letters inside envelopes": the HTTP data inside a TCP segment, that inside an IP packet, that inside an Ethernet frame. The OSI model gives each envelope a formal name: PDU (Protocol Data Unit).

On the sender, the data goes down through the layers and each one adds its header (encapsulation). On the receiver, the bits go up and each layer removes and processes the header that belongs to it (decapsulation). The frame is the only envelope that gets opened and rebuilt at every hop along the way (each router decapsulates it up to layer 3 and re-encapsulates it for the next stretch, as we saw with the ping's journey to Bilbao); the packet, the segment and the data travel end to end.

Let's replay the panoramic scene from module 2 — Marta opens intranet.grupomeridiano.example from her PC (192.168.10.21) — but now with the OSI map in front of us and all seven layers named:

Notice the symmetry: what goes down at one end comes up at the other, layer by layer and in reverse order. Since the message travels within the same local network (192.168.10.0/24), the switch only takes part in layers 1-2 and there is no router in between. If Marta queried the Bilbao printer, the packet would additionally cross both sites' routers and the VPN, which operate up to layer 3, just as we saw in 02-03.

This tour reveals an important detail about the intermediate devices: each one "climbs" only as high as the layer it needs to do its job:

• A hub or repeater only reaches layer 1: it regenerates signals without understanding anything.
• A switch climbs to layer 2: it reads the destination MAC and decides the output port.
• A router climbs to layer 3: it reads the destination IP and decides the next network.
• Only the endpoints (Marta's PC and the server) run through all seven layers.

Here is the model's immediate practical value. When something fails on the network, the OSI model gives you an ordered checklist: start at the bottom and work upward. The golden rule of support is "layer 1 first": most everyday faults are a loose cable, a powered-off device or a badly crimped wall jack, and there is no point analyzing DNS if the cable is unplugged.

An example with Meridiano: Ana, in Valencia, calls saying "the intranet isn't working for me". A layer-by-layer diagnosis:

If the ping to the default gateway works but the intranet won't load, you have already ruled out layers 1 through 3 and can concentrate higher up. That ability to discard entire halves of the problem with one simple test is what makes the OSI model the most profitable diagnostic tool you will learn in this course, and we will use it in every lesson to come.

• Believing OSI is software or a protocol that "runs" on the machines. It is a reference model: a map for thinking and communicating. Real protocols (IP, TCP, HTTP...) are described with it, but they don't implement it literally.
• Confusing the number with importance. Layer 7 is not "better" than layer 1; the number only indicates the position in the stack. In fact, without layer 1 there is nothing at all.
• Memorizing the layers without their PDUs and devices. Being able to recite "physical, data link, network..." is worth little; what's useful is associating each layer with its data unit, its addresses and its devices. This lesson's table is the one you must master.
• Starting the diagnosis at the top. Faced with a failure, the temptation is to look at the application ("could it be the browser?"). Discipline: layer 1 first. It is the quickest check and the most frequent cause.
• Tip: when you read documentation or listen to other technicians, translate mentally into layers ("layer 3 firewall", "layer 7 load balancer"). In a few weeks the model will stop being theory and become your natural way of thinking.

Exercise 1. Classify each item into its OSI layer (1-7): (a) the MAC address of the Bilbao printer, (b) port number 443, (c) the twisted pair cable joining Marta's PC to the switch, (d) the address 192.168.20.1, (e) HTTP's GET method, (f) the intranet's TLS encryption, (g) the Valencia switch.

Exercise 2. Jon, in Bilbao, cannot open the Valencia intranet. Order these checks according to the "layer 1 first" rule and state the layer of each one: (a) ping 192.168.10.10, (b) look at whether the PC's network port LED is lit, (c) try https://intranet.grupomeridiano.example in the browser, (d) ping 192.168.20.1 (his default gateway), (e) check that the cable is properly plugged in.

Exercise 3. True or false, with justification: (a) "The Valencia router processes all seven layers of every packet it forwards". (b) "The TCP on Marta's PC communicates logically with the TCP on the server, even though physically everything travels over the wire". (c) "If I swap my laptop's Wi-Fi for an Ethernet cable, I must also reconfigure TCP and HTTP".

Solution 1. (a) Layer 2 — MACs are physical data-link addressing. (b) Layer 4 — ports are transport addressing. (c) Layer 1 — the physical medium. (d) Layer 3 — it's an IP address (the Bilbao router's). (e) Layer 7 — HTTP is an application protocol. (f) Layer 6 — encryption is a presentation service (we will see it in 03-07). (g) Layer 2 — the switch decides using MAC addresses.

Solution 2. Correct order: (e) cable plugged in — layer 1; (b) port LED — layer 1 (confirms physical signal); (d) ping to the default gateway 192.168.20.1 — layer 3 within his local network; (a) ping to the server 192.168.10.10 — layer 3 across the VPN; (c) try it in the browser — layers 5-7 (DNS, TLS, HTTP). Each step that works rules out all the lower layers for the next one.

Solution 3. (a) False: a router climbs only to layer 3 (it reads the destination IP, decides the route, rebuilds the layer 2 frame for the next stretch); it looks at neither ports nor application content. (b) True: this is the peer-to-peer communication principle; the TCP-TCP dialogue is logical and travels encapsulated by the lower layers. (c) False: switching from Wi-Fi to cable only affects layers 1 and 2; the independence between layers guarantees layers 3-7 stay untouched.

You now hold the complete map: the OSI model is a seven-layer reference framework, created by ISO in 1984, which is not software but a shared language. Each layer serves the one above, uses the one below, and converses logically with its peer at the other end; encapsulation now has formal names (data, segment, packet, frame, bits), and the model gives you a diagnostic methodology: layer 1 first. The four lower layers will ring a bell from module 2, and the three upper ones are the novelty we will unpack step by step. The plan for the rest of the module is to walk the map from bottom to top, layer by layer, starting where everything physically begins: bits over copper, glass or air. That is the physical layer, and it is the next lesson.