Encapsulation Across Layers

Encapsulation is the process by which a protocol layer takes the data unit handed to it by the layer above, prepends (and sometimes appends) its own control information, and passes the result down to the layer below. The control information added at each layer is called a header (or, less commonly, a trailer, when appended at the end, as in Ethernet's frame check sequence). Crucially, the layer performing encapsulation does not parse or modify the payload it receives — it treats that payload as an uninterpreted string of bits, a property sometimes called payload opacity. The nesting produces a strict naming hierarchy for protocol data units (PDUs) as data descends the stack. Application data (a message, a file chunk, an HTTP request) becomes, once wrapped with a transport header, a segment (TCP) or datagram in the informal sense (UDP uses "datagram" too, causing some naming overlap — this article uses "segment" for the transport-layer PDU regardless of protocol, following common convention). The segment, wrapped with a network-layer header, becomes an IP datagram, often just called a packet. The datagram, wrapped with a link-layer header and trailer, becomes a frame. The frame, finally, is transmitted as a raw sequence of bits over some physical medium. Two structural facts make this system work. First, encapsulation is strictly nested, never interleaved: layer L's header sits immediately outside layer L's payload, and that payload is itself the complete output of layer L+1. Second, the process is symmetric and invertible: the receiving stack performs decapsulation, stripping headers off in exactly the reverse order they were added, at the exact matching layer, before passing the remaining payload upward. This reverse-order stripping is what lets a transport-layer process on the receiving host see only the segment header and the original application data — every header added below it in the stack has already been consumed and discarded.

Consider a host sending application data to a remote host across a network of routers and links. The full round trip involves encapsulation on the way down at the sender, forwarding through the network, and decapsulation on the way up at the receiver.

Step 1 — Application layer. The application produces a chunk of data (an HTTP request, a DNS query, a chat message). This data unit is handed to the transport layer with no header yet — it is just a byte stream or datagram of application semantics.

Step 2 — Transport layer encapsulation. The transport layer (TCP or UDP) prepends a transport header containing source port, destination port, and protocol-specific control fields (sequence numbers and acknowledgment numbers for TCP; length and checksum for UDP). The result is a segment: ``` segment = transport_header || application_data ```

Step 3 — Network layer encapsulation. The network layer (IP) prepends a network header containing source IP address, destination IP address, time-to-live, protocol number, and other routing-relevant fields. The result is a datagram: ``` datagram = network_header || segment = network_header || transport_header || application_data ```

Step 4 — Link layer encapsulation. The link layer prepends a link header (containing, for Ethernet, source and destination MAC addresses and an EtherType field) and appends a trailer (a frame check sequence for error detection). The result is a frame: ``` frame = link_header || datagram || link_trailer = link_header || network_header || transport_header || application_data || link_trailer ```

Step 5 — Physical layer transmission. The physical layer takes the frame and converts it into a signal — voltage levels, light pulses, or radio waveforms — that is transmitted across the medium bit by bit. No further header is added; the physical layer's job is signal encoding, not data structuring.

Step 6 — Intermediate devices. A crucial subtlety: not every device on the path processes every layer. A link-layer switch only decapsulates as far as the link header, reads the destination MAC address, and re-encapsulates the same frame (or a new frame with updated link header) toward the next hop — it never touches the network or transport headers. A router, by contrast, decapsulates all the way to the network layer, reads the destination IP address, decrements the TTL, recomputes the header checksum, and then re-encapsulates the datagram inside a new link-layer frame appropriate for the next link (a different link header, and possibly a different frame format entirely, e.g., Ethernet in, PPP out). This is why the link header changes hop by hop while the network header largely persists end to end.

Step 7 — Receiver decapsulation. At the destination host, the reverse process occurs, strictly layer by layer, from bottom to top: ``` physical layer: recovers frame from raw bits link layer: strips link_header and link_trailer, checks FCS, passes datagram up network layer: strips network_header, checks TTL/checksum, passes segment up transport layer: strips transport_header, checks port/checksum, passes application_data up application: receives the original application_data, unchanged ``` Here is this entire cycle expressed as language-agnostic pseudocode, first for the sending stack, then for a router, then for the receiving stack. ``` // ---- SENDER: encapsulation ---- function SEND(app_data, dst_ip, dst_port, src_port): segment = TRANSPORT_HEADER(src_port, dst_port, ...) + app_data datagram = NETWORK_HEADER(local_ip, dst_ip, TTL=64, proto=TCP_OR_UDP, ...) + segment dst_mac = ARP_RESOLVE(next_hop_ip(dst_ip)) // resolve link-layer address frame = LINK_HEADER(local_mac, dst_mac, ethertype=IPV4) + datagram + LINK_TRAILER(FCS(datagram)) PHYSICAL_TRANSMIT(frame) // convert frame to bits/signal

// ---- INTERMEDIATE ROUTER: partial decapsulation + re-encapsulation ---- function ROUTER_FORWARD(incoming_bits): frame = PHYSICAL_RECEIVE(incoming_bits) if not CHECK_FCS(frame): drop(frame); return // link-layer error detected, discard datagram = STRIP_LINK_HEADER_AND_TRAILER(frame) // decapsulate ONE layer only datagram.ttl = datagram.ttl - 1 if datagram.ttl == 0: send_icmp_time_exceeded(); return if not CHECK_HEADER_CHECKSUM(datagram): drop(datagram); return out_iface, next_hop_ip = LOOKUP_ROUTE(datagram.dst_ip) // forwarding table lookup next_hop_mac = ARP_RESOLVE(next_hop_ip) new_frame = LINK_HEADER(out_iface.mac, next_hop_mac, ethertype=IPV4) + datagram + LINK_TRAILER(FCS(datagram)) // re-encapsulate for next link PHYSICAL_TRANSMIT_ON(out_iface, new_frame)

// ---- RECEIVER: decapsulation ---- function RECEIVE(incoming_bits): frame = PHYSICAL_RECEIVE(incoming_bits) if not CHECK_FCS(frame): drop(frame); return // corrupted frame, discard silently datagram = STRIP_LINK_HEADER_AND_TRAILER(frame) if datagram.dst_ip != my_ip: drop(datagram); return // not addressed to this host if not CHECK_HEADER_CHECKSUM(datagram): drop(datagram); return segment = STRIP_NETWORK_HEADER(datagram) if not CHECK_TRANSPORT_CHECKSUM(segment): drop(segment); return app_data = STRIP_TRANSPORT_HEADER(segment) dst_socket = LOOKUP_SOCKET(segment.dst_port) DELIVER(dst_socket, app_data) // finally reaches the application ``` The pseudocode makes the layer-independence explicit: `ROUTER_FORWARD` never inspects `segment` fields, and `SEND`'s transport step never inspects link-layer addresses. Each function only reads the header it is responsible for and treats everything else as an opaque blob to pass along.

Space overhead. If application data has length $D$ bytes, and the transport, network, and link headers (plus trailer) have fixed sizes $H_T$, $H_N$, $H_L$ bytes respectively, the total frame size is

For common values — TCP header 20 bytes (no options), IPv4 header 20 bytes (no options), Ethernet header+trailer 18 bytes — the fixed overhead is $H_T+H_N+H_L = 58$ bytes regardless of $D$. This overhead is constant per frame, not proportional to $D$, so the fractional overhead $\frac{58}{D+58}$ shrinks as $D$ grows — a direct argument for why protocols batch data into larger segments when the link's maximum transmission unit (MTU) allows it, rather than sending many tiny frames. If $D$ exceeds what a single frame can carry (bounded by the link's MTU minus header sizes), the network or transport layer must fragment the data across multiple PDUs, each carrying its own full set of headers — multiplying the constant overhead by the fragment count.

Time complexity of encapsulation/decapsulation. Each layer's encapsulation step is $O(1)$ additional work beyond copying or referencing the payload: writing a fixed-size header is constant-time regardless of payload size, assuming the payload itself is passed by reference (as in real kernel network stacks, which use scatter-gather buffer chains rather than copying data at every layer). If implementations do copy the payload at each layer (a naive model), total work becomes $O(D)$ per layer and $O(k \cdot D)$ across $k$ layers — still linear in data size, not quadratic, because each layer touches the data at most once. Real operating-system network stacks avoid even this by using techniques like the BSD `mbuf` chain or Linux `sk_buff`, which reserve headroom for headers and prepend in place, making the actual per-layer cost $O(1)$.

Correctness argument. The correctness property to prove is: decapsulation exactly recovers, at each layer, the payload that was encapsulated at the matching layer on the sending side — assuming no bit errors and no drops. This follows from a simple structural invariant maintained inductively over the four encapsulation steps: Invariant: After encapsulation at layer $L$, the constructed PDU has the form $\text{header}_L \Vert \text{PDU}_{L+1}$, where $\Vert$ denotes concatenation and $\text{PDU}_{L+1}$ is exactly the unmodified PDU produced by layer $L+1$. Base case: At the application layer, $\text{PDU}_{\text{app}}$ is the raw application data — no header, trivially satisfying the invariant vacuously. Inductive step: Suppose layer $L+1$ has correctly produced $\text{PDU}_{L+1}$ satisfying the invariant. Layer $L$'s encapsulation function is defined as literal concatenation, $\text{PDU}_L = \text{header}_L \Vert \text{PDU}_{L+1}$, with $\text{header}_L$ having a fixed, self-describing length (either a fixed byte count, as in Ethernet's 14-byte header, or a length field embedded in the header itself, as in IP's Internet Header Length field). Because the header's length is always determinable — either fixed by protocol specification or explicitly encoded — the boundary between $\text{header}_L$ and $\text{PDU}_{L+1}$ is unambiguous. Decapsulation correctness: Because header length is always determinable from the header itself (fixed size or explicit length field), the receiving layer $L$ can always locate the exact byte offset where $\text{PDU}_{L+1}$ begins, regardless of the contents of $\text{PDU}_{L+1}$. This is precisely the payload-opacity property: layer $L$ never needs to interpret $\text{PDU}_{L+1}$'s internal structure to know where it ends (it doesn't — it only needs to know where its own header ends, and everything after that offset, to the end of the received PDU, is $\text{PDU}_{L+1}$ by definition of concatenation). By induction, this holds at every layer, so decapsulation at the receiver recovers exactly the original application data. $\blacksquare$

Honest tradeoffs. This clean nesting is elegant but not free. Header overhead is real bandwidth cost, especially punishing for small payloads (voice packets, IoT telemetry) where headers can dwarf the data itself. Strict layering also forbids "shortcuts" — a router cannot glance at a TCP port number without fully decapsulating to the transport layer, which is why techniques like deep packet inspection or layer-violating optimizations (e.g., TCP fast-open, or middleboxes that rewrite port numbers) are considered layering violations, and why they are fragile and controversial. Fragmentation, triggered when a datagram exceeds a link's MTU, multiplies header overhead and — for IPv4 — pushes reassembly complexity onto the receiving host, a well-known source of both performance loss and security vulnerabilities (fragmentation-based attacks exploit ambiguity in reassembly).

Trace a single 12-byte application message — the ASCII string `"PING-REQUEST"` — sent over UDP/IPv4/Ethernet, from a laptop (IP `192.168.1.10`, MAC `AA:AA:AA:AA:AA:AA`) to a server (IP `203.0.113.5`, MAC reached via a local router/gateway MAC `BB:BB:BB:BB:BB:BB`).

Now trace what the gateway router sees and does. It receives the 58-byte frame, checks the FCS (assume it passes), and strips the Ethernet header/trailer — recovering the 40-byte IP datagram. It decrements TTL from 64 to 63, recomputes the IP header checksum (since TTL changed), looks up `203.0.113.5` in its forwarding table, and finds it should go out a different interface toward the next router, with a different destination MAC (say `CC:CC:CC:CC:CC:CC`, that next router's MAC) and a different source MAC (the gateway's own outbound-interface MAC, `DD:DD:DD:DD:DD:DD`). It builds a brand-new Ethernet header around the same 40-byte IP datagram (TTL now 63) and transmits a new 58-byte frame. Note precisely what changed and what did not:

This table is the clearest evidence of the encapsulation discipline in action: the link header is entirely rewritten at every hop, while the network and transport headers, and the application payload, pass through untouched until the final destination host performs full decapsulation and delivers the 12 bytes `"PING-REQUEST"` to the UDP socket listening on port 7 — bit-for-bit identical to what the laptop's application originally sent.

The encapsulation discipline did not spring from one paper; it crystallized as ARPANET engineers and later TCP/IP designers repeatedly rediscovered that clean interfaces between independently evolving protocols required strict, nested data unit boundaries.

Every packet sniffer (Wireshark, tcpdump) is fundamentally an encapsulation-parsing tool: it reads a captured frame and displays the nested headers exactly in the order this article describes, letting engineers diagnose whether a problem lives at the link, network, or transport layer. Network interface cards and kernel network stacks (Linux's `sk_buff`, BSD's `mbuf`) are engineered around efficient encapsulation and decapsulation, reserving header space in memory buffers to avoid costly copies at each layer — directly reflecting the $O(1)$-per-layer complexity argument above. Firewalls and load balancers make routing and filtering decisions by decapsulating to specific layers (a Layer-4 load balancer reads transport ports; a Layer-7 proxy decapsulates all the way to application data). Tunneling protocols like VPNs, GRE, and VXLAN deliberately exploit encapsulation by wrapping an entire frame or datagram inside another protocol's payload, creating "encapsulation within encapsulation" — a technique only comprehensible once the base nesting discipline is understood. Understanding this mechanism is the direct prerequisite for studying The Link Layer: Role and Services, where the specific job of the innermost header — addressing, framing, and error detection on a single physical link — is examined in depth.

Ask the tutor: How does encapsulation change when a VPN tunnels one full IP packet inside another?