What Is the DNP3 Data-Link Layer?
DNP3 is often drawn as three stacked layers, and the bottom one - the data-link layer - is where a raw stream of bytes becomes a framed, addressed, error-checked message. If you are decoding a capture or explaining why a message with a good payload still gets rejected, you need to understand what the link layer does with every frame before the application layer ever sees it. This page describes the DNP3 link frame, its header fields, and the per-block CRC that lets a receiver trust what it got.
DNP3 Data-Link Layer in one line: The DNP3 data-link layer is the lowest of the three DNP3 layers. It wraps outgoing data in a frame that begins with the sync bytes 0x0564, a length byte, a control byte, and 16-bit source and destination link addresses, then appends a two-byte CRC after the header and after every 16-byte data block. The receiver checks each CRC, confirms the frame is addressed to it, and only then hands the payload up to the transport function.
The Frame Header and Its Fields
Every DNP3 link frame opens with the same fixed pattern so a receiver can find the start of a message in a byte stream. The first two bytes are the start pattern 0x05 0x64, a signature that says a DNP3 frame follows. Next comes a length byte that counts the bytes in the rest of the header and the user data, then a control byte that carries direction, primary/secondary, and function-code bits used by the link-layer state machine.
After the control byte come two 16-bit fields that matter most to an integrator: the destination address and the source address. The destination says which outstation or master the frame is for, and the source says who sent it. These are DNP3 link addresses, not IP addresses; on a TCP link both still travel inside the frame, which is why one IP endpoint can host several logical DNP3 devices. Getting these fields right is the whole subject of the DNP3 master and outstation address concept.
The CRC on Every Block
DNP3 does not put one checksum at the end of a message and hope. It appends a 16-bit CRC immediately after the 8-byte header block, and then after every 16-byte block of user data that follows. A long frame therefore carries many CRCs, each protecting a small chunk. This design comes from DNP3's origin on noisy serial and radio links, where a single end-of-message checksum could miss a burst error buried in a long frame.
For a receiver, the rule is simple: if any block CRC fails, the frame is discarded and never reaches the application layer. That is why a payload that looks correct in isolation can still be dropped - the failure lives in the framing, not the data. When you troubleshoot silent DNP3 links, the link layer is the first place to rule out, much as a serial CRC error points at wiring and noise rather than at the protocol logic above it.
Where the Link Layer Sits in the Stack
DNP3 uses a simplified three-layer model - link, transport (technically a pseudo-transport function), and application - rather than the full seven-layer OSI stack. The link layer's job ends once it has validated a frame and confirmed the addressing. It does not know what the data means; it only guarantees that a correctly addressed, uncorrupted frame is delivered up the stack, or that a bad one is dropped.
On a serial multidrop bus the link layer also carries the addressing that lets many outstations share one pair of wires, since each frame names its destination. On TCP the physical delivery is handled by the network, but the link frame is transmitted intact so that DNP3 addressing, framing, and per-block CRC still apply. Understanding that split is the key to reading a capture: the link fields tell you who and whether the frame is intact, and the layers above tell you what it says.
Frequently Asked Questions
How many CRCs are in one DNP3 frame?
One CRC follows the 8-byte header, and one follows each 16-byte block of user data. A short frame has two CRCs; a long frame has many. Every one must pass for the frame to be accepted, which is what makes DNP3 framing robust on noisy links.
What are the DNP3 sync bytes?
Every DNP3 link frame starts with 0x05 0x64. A decoder searches the byte stream for that pattern to lock onto the beginning of a frame, then reads the length and control bytes that follow it.
Is the DNP3 link address the same as the IP address?
No. On DNP3 over TCP the link frame still carries 16-bit source and destination link addresses inside the payload, independent of the IP address of the endpoint. That is how one IP host can present multiple logical DNP3 outstations.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.