Visual walkthrough — OSI model — 7 layers, responsibilities, PDU names

We build every word from zero. If a term shows up, it gets a picture first.

---

Step 1 — The two towers and the one wire

WHAT: Draw Machine A's tower on the left, Machine B's tower on the right, and the single physical wire connecting their basements.

WHY: Every later step is "which floor are we on, and which direction (down on A, up on B)". You need this map fixed in your head before any symbol appears.

PICTURE: Look at the amber arrow — it goes down the left tower, across the wire at the bottom, and up the right tower. Data never jumps sideways between upper floors. The only real crossing is on the wire.

Recall Why can't Layer 7 on A talk straight to Layer 7 on B?

Because there is no wire between the top floors — only the basements touch. Answer ::: the message MUST travel all the way down A, across the one wire, and all the way up B.

---

Step 2 — The payload starts as pure Data (but Layers 6 & 5 may reshape it)

WHAT: Show "Hi" as a bare cyan box at Layer 7, then show what Layers 6 and 5 can do to the payload itself before Transport ever sees it:

• Layer 6 (Presentation) — the translator. It may compress the payload (make it smaller) or encrypt it (scramble it, e.g. TLS). The bytes that come out are different bytes — this is the one place the payload content is legitimately changed, not just wrapped.
• Layer 5 (Session). Before any data flows it runs a small handshake to open a session, and it can insert checkpoints so a failed transfer resumes instead of restarting. Some of this adds a little session bookkeeping to the payload.

WHY show this? Everywhere below Transport is pure wrapping (headers glued on, content sealed). Above Transport is the only place the content can actually transform. Students who think "nothing happens in 5/6/7" get confused by why an encrypted payload looks like noise — this step is where that noise is born.

PICTURE: Left: the bare "Hi" box. Middle: Layer 6 turns it into a smaller/scrambled box "§q". Right: Layer 5 adds a tiny session tag. The size may go down (compression) or stay similar (encryption) — it is not always additive up here.

Let us name the size of whatever leaves Layer 5 (compressed/encrypted or not) so we can track growth from here down:

$D=\text{size in bytes of the (possibly compressed/encrypted) payload handed to Transport}$

For our plain example we take $D=2$ bytes (the raw "Hi", no compression).

• $D$ ::: the bytes handed down to Layer 4 — after any Presentation/Session transformation, before any lower header.

---

Step 3 — Transport adds a header → the box becomes a Segment

WHAT: The Transport layer (Layer 4) prepends a header $h_T$. The box [ h_T | Data ] now has a new name: Segment (this is TCP's name; UDP calls it a Datagram).

WHY this layer, this header? Layer 4's job is end-to-end to the right program. A machine may run a browser AND an email client at once. The header carries a port number so the far machine knows which program gets the box — port 443 → browser, not email.

PICTURE: The amber header block clamps onto the front of the cyan Data box. Nothing inside the Data box changes — it is sealed and carried whole. That "seal and carry, never peek" idea is the heart of layering.

$\underset{\text{Transport header (ports, seq \#)}}{\underbrace{h_T}}+\underset{\text{your data, untouched}}{\underbrace{D}}=S$

• $h_T$ ::: bytes the Transport layer adds — port numbers, sequence/ack numbers.
• $S$ ::: the Segment size, $S=h_T+D$. Note $S>D$: adding a header always makes the bundle bigger.

---

Step 4 — Network adds a header → the Segment becomes a Packet

WHAT: The Network layer (Layer 3) wraps the whole Segment with its own header $h_N$. New bundle [ h_N | h_T | Data ], new name: Packet.

WHY this layer? The Segment knows the right program but not the right machine across the planet. Layer 3 stamps the destination IP address so a router (Routers vs Switches vs Hubs) can forward the packet hop-by-hop across many networks. Crucially, Layer 3 treats the whole Segment (header + data) as opaque cargo — it does not open it.

PICTURE: A second, outer header (cyan this time) clamps around the entire Segment from Step 3. Notice the nesting — like envelopes inside envelopes. This nesting is exactly what Encapsulation and De-encapsulation means.

$\underset{\text{Network header: source + dest IP}}{\underbrace{h_N}}+\underset{\text{the whole Segment }S,\text{ sealed}}{\underbrace{(h_T+D)}}=P$

• $h_N$ ::: the IP header — carries source and destination IP addresses for routing.
• $P$ ::: the Packet size, $P=h_N+S=h_N+h_T+D$.

---

Step 5 — When the Packet is too big for the link: fragmentation

WHAT: If the Packet $P$ is larger than the link's MTU, the Network layer fragments it: it chops the Packet into several smaller packets, each with its own copy of the IP header $h_N$, and marks them with a fragment offset so the far side knows the order. The receiver's Layer 3 reassembles them back into the original Packet before handing it up.

WHY this step exists? Layers 4 and above happily produce a big Segment; they have no idea what wire it will cross. The link, however, cannot swallow a bundle bigger than its MTU. Fragmentation is Layer 3's way of reconciling "big logical packet" with "small physical link" — without it, oversized data simply could not cross.

PICTURE: One long Packet on top; below it, three shorter packets, each re-stamped with its own $h_N$ (so total header bytes go up), each tagged offset 0, 1, 2. An amber arrow on the right shows the receiver gluing them back into the original.

$\text{if }P>\text{MTU:}P⟶{\text{frag}}_0,{\text{frag}}_1,\dots \text{each }\le \text{MTU,}\text{each carrying its own }{h}_N$

• $\text{MTU}$ ::: hardware byte-ceiling of the link.
• Each fragment repeats $h_N$ ::: fragmentation adds overhead — more headers than the single un-fragmented packet.

For our tiny "Hi", $P$ is only a handful of bytes — far under any MTU — so no fragmentation happens and exactly one packet continues down. We keep following that single packet.

---

Step 6 — Data Link adds a header AND a trailer → Packet becomes a Frame

WHAT: The Data Link layer (Layer 2) adds a header $h_L$ at the front and a trailer $t_L$ at the back. Bundle [ h_L | h_N | h_T | Data | t_L ], new name: Frame.

WHY a header AND a trailer? Layer 2 delivers node-to-node on one physical link (your PC → the router in the room). The header carries the local MAC addresses; the trailer carries a checksum so the receiver can tell if the bits got scrambled on the wire. This is the ONLY layer that wraps on both ends.

PICTURE: Header clamps the front, trailer clamps the back — the box is now sealed on both sides. Everything from Step 4 is nested inside.

$\underset{\text{L2 header: MAC addrs}}{\underbrace{h_L}}+\underset{\text{the whole Packet }P}{\underbrace{(h_N+h_T+D)}}+\underset{\text{trailer: CRC error-check}}{\underbrace{t_L}}=F$

Let $F$ name the Frame size in bytes. Then, matching the parent note's formula:

$\boxed{F=D+h_T+h_N+h_L+t_L}$

• $F$ ::: the size of the finished Frame — the bytes the Data Link layer hands to the Physical layer.
• Every term is a + — encapsulation is purely additive — nothing your app typed is ever removed, only surrounded. That is why network overhead exists.

---

Step 7 — Physical turns the Frame into Bits — plus its own on-wire extras

WHAT: The finished Frame $F$ is flattened into a line of 0s and 1s. On real Ethernet, Layer 1/the interface also sends, around each frame:

• a preamble (7 bytes) + start-of-frame delimiter (1 byte) — a warm-up pattern so the receiver's clock synchronises and knows "a frame begins now";
• an inter-frame gap (equivalent of 12 bytes of idle) — mandatory silence between frames.

WHY show this? Because a packet-capture / speed calculation counts these too. If a student computes $F=D+h_T+h_N+h_L+t_L$ and then measures the wire, the wire number is slightly bigger. The gap is these physical extras. The clean formula gives the Frame; the wire gives the Frame plus signalling overhead.

PICTURE: The boxed Frame $F$ dissolves into a wavy signal 10110... travelling left→right, with an amber preamble/SFD burst before it and an amber idle gap after it, each labelled.

$\text{on-wire bytes}=\underset{\text{our Frame}}{\underbrace{F}}+\underset{8\text{ bytes}}{\underbrace{(\text{preamble}+\text{SFD})}}+\underset{12\text{ bytes idle}}{\underbrace{\text{inter-frame gap}}}$

• These extras belong to Layer 1 signalling ::: they are not part of $F$, which is why our formula stays $F=D+h_T+h_N+h_L+t_L$ while the wire shows a bit more.

---

Step 8 — The climb up B: de-encapsulation peels the wrappers in reverse

WHAT: Machine B receives bits → drops the physical extras and rebuilds the Frame (L2) → strips $h_L,t_L$ to get the Packet (L3) → reassembles any fragments and strips $h_N$ to get the Segment (L4) → strips $h_T$ to get the Data → Layer 6 decrypts/decompresses it back to the original bytes → the app receives "Hi".

WHY reverse order (last wrapped, first opened)? The outermost wrapper is the one the lowest layer added, so the lowest layer on B is the one who can read and remove it. Each layer opens exactly the header written by its twin layer on A. Note the symmetry even for content changes: Layer 6 on A encrypted, Layer 6 on B decrypts.

PICTURE: The two towers side by side. Solid amber arrow falls down A (adding wrappers / transforming content), solid cyan arrow rises up B (removing them / undoing transforms). Faint dashed "peer" lines connect each floor on A to the same floor on B.

Recall If B's switch only reads up to Layer 2, does it see your

"Hi"? A switch/router that stops at Layer 2 only strips and re-writes the Frame header to forward it locally. Answer ::: it never opens the inner Packet, so it never sees the payload — each device climbs only as high as its job needs.

---

Step 9 — More edge & degenerate cases

---

The one-picture summary

Below: the whole journey on one canvas. Left tower = A falling down, each floor stamping a coloured wrapper (and Layers 6/5 transforming the content); the wire in the middle carrying bits with their signalling extras; right tower = B climbing up, peeling those same wrappers off. Read the box sizes bottom-to-top and watch them grow, then shrink.

Recall Feynman retelling — say the whole thing back in plain words

Explain the walkthrough to a friend with no jargon. Retelling ::: I want to send the word "Hi" to a computer far away. My machine has a tower of 7 helpers. The top helper (my app) hands "Hi" down. Helper 6 may scramble it (encrypt) or squeeze it (compress) so it now looks like noise — that is the one place the content itself changes. Helper 5 opens a session and can drop resume-checkpoints. The 4th helper (Transport) writes a note saying which program should get it, renaming the bundle a Segment. The 3rd helper (Network) wraps that with the far machine's internet address, calling it a Packet — and if the packet is bigger than the wire can carry, it chops it into fragments, each with its own address note. The 2nd helper (Data Link) wraps it once more with the local device address on the front and an error-check code on the back, calling it a Frame. The 1st helper (Physical) turns the frame into 0s and 1s, adds a warm-up pattern and a mandatory gap, and pushes them onto the wire. On the other machine the same 7 helpers work in reverse: rebuild the frame, glue fragments back, peel off each note, then helper 6 un-scrambles the content, until the top helper hands the clean word "Hi" to the app. Nothing my app meant was lost — it was wrapped, sometimes scrambled, then unwrapped and un-scrambled again, which is why the message on the wire is bigger and scarier-looking than "Hi" itself.

Recall Order of the PDU names, bottom to top

Bit → Frame → Packet → Segment → Data. Mnemonic ::: "Big Fat Pandas Sleep Deeply"

See also: TCP-IP Model — 4 vs 5 layers, Ports and Sockets, Encapsulation and De-encapsulation.