The OSI and TCP/IP Reference Models

A reference model is an architectural blueprint that partitions the enormous problem of "make two computers communicate reliably over arbitrary physical media" into a stack of smaller, independent sub-problems called layers. Each layer n on a given host exposes a service to layer n+1 above it through a service access point, and that service is implemented using only the service that layer n−1 provides below it. Layer n on one machine communicates conceptually with the peer layer n on the remote machine, using a protocol — a set of rules governing the format and meaning of the messages exchanged. Crucially, layer n has no idea how layer n−1 actually moves bits; it only trusts the interface contract. The OSI Reference Model, standardized by the International Organization for Standardization in 1984, defines exactly seven such layers, from Physical (raw bit transmission) up through Application (the end-user program). It was designed prescriptively, as an abstract framework meant to guide the creation of new protocols, largely independent of what was already running on real networks. The TCP/IP Reference Model (sometimes called the Internet model) instead was reverse-engineered from the actual protocol suite — IP, TCP, UDP, and the applications built on them — that had already been running successfully on the ARPANET and its successors. It compresses networking into five layers (in the version most textbooks teach): Physical, Link (Data Link), Internet (Network), Transport, and Application. Some presentations merge Physical and Link into a single "Network Access" layer, giving a four-layer version; this article uses the five-layer form because it aligns cleanly, layer-for-layer, with the bottom four layers of OSI, which is the version most useful for teaching and for later material on Encapsulation Across Layers and The Link Layer: Role and Services.

The seven OSI layers, bottom to top

1. Physical layer — moves individual bits over a physical medium (copper, fiber, radio). Concerns: voltage levels, bit timing, connector pinouts, modulation. 2. Data Link layer — groups bits into frames, handles framing, addressing between adjacent nodes on the same link (e.g., MAC addresses), and basic error detection. Some Data Link protocols also do error correction or media access control. 3. Network layer — routes packets across multiple links from source host to destination host, potentially through many intermediate routers. Handles logical addressing (e.g., IP addresses) and path selection. 4. Transport layer — provides end-to-end delivery between processes on the source and destination hosts, e.g., reliable byte-stream delivery, flow control, or unreliable best-effort delivery, and (in some protocols) congestion control. 5. Session layer — establishes, manages, and terminates sessions: dialogues between two communicating applications, including synchronization checkpoints and dialogue control (who talks when). 6. Presentation layer — handles the syntax and semantics of the data exchanged: character encoding, data compression, encryption/serialization formats, so that two hosts with different internal data representations can understand one another. 7. Application layer — the layer the end-user application actually interacts with: protocols for file transfer, e-mail, web browsing, and so on.

The five TCP/IP layers, bottom to top

1. Physical layer — identical role to OSI's; not formally specified by the original TCP/IP documents but universally included in the modern teaching diagram. 2. Link layer (also called Network Access or Network Interface layer) — corresponds to OSI's Data Link layer: framing, physical addressing, media access on a single link. 3. Internet layer — corresponds to OSI's Network layer. This is where the Internet Protocol (IP) lives: logical addressing and best-effort routing across many networks. 4. Transport layer — corresponds directly to OSI's Transport layer. TCP (reliable, connection-oriented, stream-based) and UDP (unreliable, connectionless, datagram-based) live here. 5. Application layer — merges OSI's Session, Presentation, and Application layers into one. Protocols like HTTP, DNS, SMTP, and FTP handle session management, data representation, and application logic all within this single layer, typically implemented as library code or logic inside the application itself rather than as separate protocol layers.

The mapping between the two

``` OSI (7 layers) TCP/IP (5 layers) -------------------------------- -------------------------------- 7 Application ┐ 6 Presentation ├──────────── Application 5 Session ┘ 4 Transport ───────────── Transport 3 Network ───────────── Internet 2 Data Link ───────────── Link 1 Physical ───────────── Physical ``` The mapping is exact and one-to-one for layers 1–4 in OSI numbering; it is many-to-one (3-to-1) at the top, where OSI's Session, Presentation, and Application collapse into a single TCP/IP Application layer. This is the single structural fact to memorize, because everything else follows from it.

Encapsulation: how data actually moves through the stack

Whichever model you use, sending data works the same way procedurally: each layer wraps the data it receives from above inside its own header (and sometimes trailer), forming a protocol data unit (PDU), then passes that PDU down to the layer below. This nested wrapping is called encapsulation, explored in depth in Encapsulation Across Layers; here is the mechanism at the level needed to understand layering itself. ``` function SEND(application_data):

# Application layer L5_PDU = APP_HEADER + application_data # e.g., HTTP request

# Transport layer L4_PDU = TRANSPORT_HEADER(src_port, dst_port) + L5_PDU # a "segment"

# Internet / Network layer L3_PDU = NETWORK_HEADER(src_IP, dst_IP, ttl) + L4_PDU # a "packet"

# Link layer L2_PDU = LINK_HEADER(src_MAC, dst_MAC) + L3_PDU + LINK_TRAILER(CRC) # a "frame"

# Physical layer transmit_bits(L2_PDU) # raw bits on the wire

function RECEIVE(bitstream): frame = physical_layer_decode(bitstream) check_and_strip(frame.LINK_TRAILER) # verify CRC packet = strip_header(frame, LINK_HEADER) if packet.dst_IP == this_host.IP: segment = strip_header(packet, NETWORK_HEADER) pdu5 = deliver_to_transport(segment, dst_port) # demultiplex by port app_data = strip_header(pdu5, APP_HEADER) deliver_to_application(app_data) else: forward(packet) # this host is a router: re-encapsulate at Link layer, resend ``` Each layer's header is meaningful only to its peer layer on the remote machine — a router forwarding a packet reads the Network-layer header but does not open the Transport-layer segment inside it; an end host's Transport layer reads the Transport header but ignores the Link-layer frame that carried it, because that frame was already stripped off by the Link layer beneath it.

Layering is not primarily a "complexity" concept in the algorithmic sense — there is no input size n to plug into a runtime formula — but it has precise engineering costs and benefits that deserve the same rigor.

Space/overhead cost. Every layer adds header bytes to the PDU. If application data has length $D$ and layers add header sizes $h_4, h_3, h_2$ (Transport, Internet, Link) plus a Link trailer $t_2$, the bits actually placed on the wire total

For a TCP/IPv4/Ethernet stack this is typically $D + 20 + 20 + 14 + 4$ bytes (ignoring options), a fixed overhead independent of $D$. This overhead is the honest "cost" of layering: it is paid on every single packet, which is why protocol designers fight hard over header sizes and why techniques like header compression exist on constrained links.

Processing cost. Encapsulation and decapsulation at each layer are $O(1)$ per layer per packet (prepend/strip a fixed-size header), so the total per-packet processing cost across $k$ layers is $O(k)$ — constant in the number of layers, since $k$ is a small constant (4 or 5), not a function of data size. The real per-packet cost is dominated by whatever each layer does beyond header manipulation — e.g., a routing-table lookup at the Internet layer, discussed under Layer 3 protocols, or checksum computation at the Transport layer, which is $O(D)$ in the payload length because every byte must be summed.

Why layering is correct (the interface argument). The correctness of a layered design rests on an invariant, not a numeric bound: > Layering Invariant. Layer n on host A only assumes the service contract published by layer n−1; it makes no assumption about how that service is implemented internally. If every layer upholds this invariant, then any layer's implementation can be swapped out — a new physical medium, a new Link-layer technology, a new routing algorithm — without requiring changes to any layer above it, provided the published service interface is unchanged. This is exactly the substitution principle behind Protocol Layering and Service Models: Wi-Fi can replace Ethernet at the Link layer, and every layer above (Internet, Transport, Application) continues working unmodified, because IP only assumes "the Link layer can deliver a frame to a neighbor," not any specific hardware detail.

Honest tradeoffs. Layering buys modularity and independent evolution at the cost of (a) header overhead on every packet, (b) some loss of efficiency compared to a hypothetical monolithic protocol that could share information across layers (e.g., a Transport-layer protocol cannot see Link-layer congestion signals directly without an explicit cross-layer mechanism), and (c) extra processing indirection. These costs are why some specialized systems (e.g., certain data-center or embedded protocols) deliberately violate strict layering for performance, at the price of tighter coupling and harder maintainability — a classic engineering tradeoff, not a flaw unique to OSI or TCP/IP.

Trace an HTTPS request from a laptop's browser to a web server, showing both models side by side. Assume the browser (`10.0.0.5`, ephemeral port `51000`) requests a page from `93.184.216.34:443`.

Two facts jump out of this trace. First, only Steps 1 and 11 ever touch OSI's Session and Presentation layers, and TCP/IP has no separate layer at all for that work — it is folded entirely into "Application," performed by libraries (TLS, HTTP parsing) linked into the application process. Second, intermediate routers (Step 6) never go above the Internet/Network layer: they read only Layer-3 headers and re-do Layer-2 framing, which is precisely why a router is correctly described as "a Layer 3 device" — it has no business, and typically no ability, to see the encrypted Transport-layer payload at all.

The OSI model emerged from international standards bodies trying to unify a fragmented, multi-vendor networking landscape in the late 1970s and early 1980s. The TCP/IP suite, in stark contrast, emerged from a working research network years before either was formally standardized as a "model," and its designers cared far more about running code than about architectural elegance.

:::physicist|Robert E. Kahn|born 1938|Co-designer of TCP/IP, architect of the ARPANET's original packet-switching principles Robert Kahn shaped the foundational principle that packets should be routed independently and reassembled at the destination, with intelligence pushed to the endpoints rather than into the network core — the "end-to-end" philosophy that still governs how the Internet and Transport layers divide responsibility today.

Every internet-connected device — from a smartphone to a satellite modem to a data-center server — runs some approximation of the TCP/IP stack, making its five-layer decomposition the operative architecture of the real internet. OSI's seven-layer vocabulary nonetheless dominates professional communication: network engineers describe switches as "Layer 2 devices," routers as "Layer 3," load balancers and firewalls as "Layer 4" or "Layer 7," and certification exams (like the CCNA) are built almost entirely around OSI numbering even while testing knowledge of TCP/IP protocols. Network monitoring and packet-capture tools (Wireshark, tcpdump) display captured traffic annotated with OSI-style layer labels even though the bytes on the wire are pure TCP/IP. Understanding both models, and precisely how they align, is prerequisite groundwork for Encapsulation Across Layers (how headers actually accumulate and get parsed) and for The Link Layer: Role and Services (a deep dive into the layer where framing, addressing, and media access control are specified in full).

Ask the tutor: Can you walk through exactly which header fields get added and stripped at each layer when a UDP-based DNS query is sent and answered?