JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Framing: Drawing Lines Around the Bits

The physical layer hands you an endless dribble of bits with no punctuation. This guide shows how the data link layer chops that river into frames the receiver can find, and the surprisingly tricky job of marking where one frame stops and the next begins.

Why bits alone are not enough

You have just climbed out of the physical layer, where the whole job was getting raw 1s and 0s across a wire or through the air. But the physical layer is honest about one thing: it delivers a continuous, undivided stream of bits, like a tap left running. It never tells you 'a message starts here' or 'this message ended'. If your friend sends you the bits for two short notes back to back, the wire just hands the other end one long unbroken trickle. Where does the first note end?

This is the first real job of the data link layer: take that featureless bit stream and draw lines around chunks of it, so the receiver can pick out self-contained units called frames. A frame is the data link layer's envelope. It is the postcard, with a header at the front (the address and a few control fields), the actual cargo in the middle, and usually a check sequence at the back. Everything the upper layers handed down, a whole network packet, rides inside as the cargo.

Anatomy of a frame

Before we worry about how to find a frame's edges, let us look at what a frame actually contains. Almost every framing format follows the same recipe: a marker that says 'a frame begins here', a header with addresses and control bits, a variable-length payload carrying the packet from above, and a trailer with an error-check field. The classic example is the Ethernet frame, which has carried the lion's share of the world's wired traffic for decades.

Read an Ethernet frame front to back and you meet the recipe in order. First a short preamble, a fixed wake-up pattern of alternating bits whose only job is to let the receiver's clock lock onto the signal; it is not really part of the frame's data. Then the header: a 6-byte destination MAC, a 6-byte source MAC, and a 2-byte type telling the receiver what kind of packet is inside. Next the payload, anywhere from 46 to 1500 bytes, where the network-layer packet rides as cargo. Finally a 4-byte trailer, the FCS, holding the error check. Header, payload, trailer: the same envelope shape every time.

Two details earn their keep here. First, the MAC addresses in the header name the source and destination hardware on this one link, a topic we will unpack fully in a later guide; for now just know each network interface has its own. Second, the trailing FCS (Frame Check Sequence) is a cyclic redundancy check, the error-detecting fingerprint covered in the next guide of this rung. The frame format already reserves a slot for catching corruption, because a link is allowed to be lossy and noisy.

The hard part: where does a frame end?

Now the genuinely tricky question. The receiver gets a bare stream of bits and must decide, with no outside help, where each frame starts and stops. This is the framing problem, and it is the same puzzle you face in message framing when you read bytes off a socket and need to know where one message ends. There are three honest strategies, and real protocols mix them.

The first idea is a length field: put a number at the front of the frame that says 'I am exactly N bytes long'. The receiver reads N, counts off N bytes, and knows the next byte starts a new frame. Clean and simple, but fragile: if a single bit in that length field gets corrupted, the receiver miscounts and loses its place for every frame after it, like skipping a line while reading a dense column of numbers. So a length field usually needs a sentinel to recover from.

The second idea is a flag: pick a special bit pattern, say 01111110, and stamp it at the start and end of every frame, like the period at the end of a sentence. The receiver just scans for the flag. This is robust, because even after an error the receiver only has to wait for the next flag to re-sync. But it raises an awkward question that gives this whole topic its flavour: what happens when the cargo data itself happens to contain the flag pattern?

Stuffing: hiding the flag from the data

Suppose your flag is the byte 01111110 and, deep inside someone's photo, that exact byte appears in the payload. If you do nothing, the receiver sees it and wrongly declares the frame finished, slicing the photo in half. The fix is stuffing: a rule that guarantees the flag pattern can never appear inside the payload by accident, while still letting any data through.

Bit stuffing is the cleverest version, used by protocols like HDLC. The flag 01111110 has six 1s in a row. The rule: whenever the sender is about to transmit five 1s in a row inside the data, it automatically inserts a 0 right after them. So the data can never produce six 1s. The receiver runs the rule backwards: after five 1s it sees a stuffed 0 and simply deletes it, recovering the original bits. Six 1s in a row can now only mean a real flag.

Bit stuffing (flag = 01111110, i.e. six 1s)

  Original data:    0 1 1 1 1 1 1 0 0 1
                            ^ five 1s here -> sender inserts a 0
  Sent on wire:     0 1 1 1 1 1 0 1 0 0 1
                              (stuffed 0, never confused with a flag)

  Receiver: after five 1s, delete the next 0  ->  back to 0 1 1 1 1 1 1 0 0 1
The sender slips an extra 0 after any run of five 1s so the data can never fake the six-1 flag; the receiver strips that 0 back out.

There is a byte-level cousin called byte (or character) stuffing, used by PPP and by the framing in many serial protocols. Instead of counting bits, it escapes any byte that collides with the flag, the same way a programming language lets you put a quote inside a string by writing a backslash before it. The principle is identical: reserve a special marker for boundaries, then carefully encode any data that would otherwise be mistaken for that marker.

Walking a frame across one link

Let us trace one frame from a sending network card to the receiver, so the pieces click together. Notice that framing, addressing, and the error-check sit side by side and all happen on this one hop. The receiver does its checks first, and only then does it bother to look at what is inside.

  1. The network layer hands down a packet. The sending card wraps it: it adds a header (destination and source MAC, plus a type field) and computes the CRC over everything, placing it in the trailing FCS.
  2. It runs stuffing over the bytes so the payload can never imitate the boundary marker, then frames the whole thing with start and end delimiters.
  3. The physical layer turns the framed bits into a signal and sends it. On the wire it is once again just a flat stream of bits, but now it carries the delimiters that let the other end find the edges.
  4. The receiving card scans for the start delimiter, reads bits until the end delimiter, and un-stuffs to recover the original payload exactly.
  5. It recomputes the CRC over the received frame and compares it to the FCS. If they match, the frame is intact and the payload, the original packet, is handed up to the network layer; if not, the frame is silently dropped and it is up to higher layers to notice and resend.