PRP-0 vs PRP-1: What Changed in IEC 62439-3, Edition by Edition

A relay datasheet says “PRP.” The switch says “PRP.” The SCADA server’s network card says “PRP.” On site, the frames still come through twice, or the supervision counters stay at zero, or a RedBox doesn’t see half the nodes.

Often the reason is that “PRP” isn’t one protocol. There are two versions on the wire, and they don’t recognise each other’s trailer. The industry calls them PRP-0 and PRP-1. The standard itself just says PRP and puts a version number in the supervision frame.

This article walks through every edition, shows exactly what changed between the two versions, and gives you a quick way to tell which one a device speaks. For the basics of how PRP works, start with the PRP complete guide.

The short answer

• PRP-0 is the original PRP. It was published in IEC 62439:2008 and carried into IEC 62439-3:2010 with only editorial changes.
• PRP-1 arrived with IEC 62439-3:2012. It changed the trailer, the sequence numbering and the duplicate discard rules so that PRP and HSR could share one design.
• 2016 and 2021 kept PRP-1. They added corrections, clock synchronisation material and clarifications, not a new wire format.

So any device built to the 2012 edition or later speaks PRP-1. A device built to the 2008 or 2010 text speaks PRP-0. The two can’t do duplicate discard with each other.

The edition timeline

Edition	Published	PRP version	What it did for PRP
IEC 62439:2008	2008	PRP-0	First PRP, as Clause 6 of a single standard that also held MRP and other protocols
IEC 62439-3:2010 (Ed. 1)	February 2010	PRP-0	The series split into parts. PRP moved to Part 3 with minor editorial changes. HSR was added beside it.
IEC 62439-3:2012 (Ed. 2)	July 2012	PRP-1	Added the PRP suffix, aligned PRP with HSR, specified PRP–HSR interconnection, added IEC 61588 clock material and test modes
IEC 62439-3:2016 (Ed. 3)	2016	PRP-1	Technical corrections, end-to-end delay PTP alongside peer-to-peer, reworked clock annexes including redundancy support for the IEC/IEEE 61850-9-3 power profile
IEC 62439-3:2021 (Ed. 4)	December 2021	PRP-1	Current edition. A corrigendum followed in April 2023.

The 2012 change list is the one that matters here. Among other things, it lists “introduction of a suffix for PRP frames” and “clarification and modification of specifications to ensure interoperability.” That suffix is the single biggest wire-level difference between the two versions.

Side by side

Here’s what changed between the 2008 text (PRP-0) and the 2016 text (PRP-1).

Item	PRP-0	PRP-1
Redundancy Control Trailer (RCT)	4 octets	6 octets
RCT fields	Sequence number (16 bit), LAN ID (4 bit), LSDU size (12 bit)	Same three fields, plus a 16-bit suffix 0x88FB
LAN ID values	1010 for LAN A, 1011 for LAN B	Same
Sequence numbering	One counter per destination	One counter per sending node
Duplicate detection key	Sequence number, tracked per LAN with drop windows	Source MAC address plus sequence number
Discard algorithm	Specified in the standard (drop window)	Not specified. Any method that never drops a real frame is allowed.
Table aging	Drop window up to 32 768 numbers	Entries purged after EntryForgetTime, 400 ms by default
Duplicate Accept mode	A normal operating mode	Testing only
Port MAC addresses	Same by default, different allowed with address substitution	Both ports use the same MAC address
Supervision version	PRP_Ver = 0	SupVersion = 1
Supervision frame size	64 octets, 68 with VLAN tag	70 octets, 74 with VLAN tag
Maximum frame on the LANs	Payload limited to 1 496 octets to stay within IEEE 802.3 sizes	Network expected to carry 1 528-octet frames
HSR compatibility	None	Same trailer fields and discard logic as HSR

The rest of the article explains the lines that matter in the field.

The trailer: four octets vs six

Both versions add a trailer just before the frame check sequence. That’s why PRP is transparent to devices that don’t know it: a single-attached node sees the trailer as padding and ignores it.

PRP-0 adds four octets: a 16-bit sequence number, a 4-bit LAN identifier and a 12-bit size field. A receiver spots a PRP frame by checking whether the last 12 bits match the actual payload size, and whether the LAN ID matches the LAN the frame came in on.

PRP-1 adds the same four octets plus two more: a fixed suffix, 0x88FB. That’s the same value as the PRP EtherType. A receiver now checks three things: the last 16 bits are 0x88FB, the 12 bits before that match the payload size, and the LAN ID matches the port.

Why add the suffix? Size matching alone can be fooled. A normal frame from a non-PRP device can, by chance, end with 12 bits that equal its own payload size. The suffix makes a false match much less likely, which matters more and more as networks mix PRP nodes, single-attached nodes and other trailers.

The size field also changed its scope slightly. In PRP-1, the LSDU size covers everything from after the EtherType to the end of the trailer, including padding, and the standard notes the intention that the value is the same in PRP and HSR.

Sequence numbers: per destination vs per node

This is the change that made PRP-1 possible.

In PRP-0, a node keeps a sequence counter for each destination it talks to. Each time it sends to that destination, that counter goes up. The receiver expects an unbroken sequence from each sender and runs a drop window on each LAN. Frames inside the other LAN’s window are duplicates. Frames outside are kept.

That works between two nodes. It falls apart when something in the middle has to recognise duplicates for many senders and many receivers, which is exactly what an HSR ring node or a PRP–HSR RedBox does.

In PRP-1, a node has one counter, SendSeq, for everything it sends. The pair “source MAC address + sequence number” identifies a frame anywhere in the network. Any device on the path can keep a table of recently seen pairs and drop the second copy. That’s the same rule HSR uses, so the same logic works in PRP nodes, HSR nodes and the RedBoxes that join them. See PRP vs HSR and the HSR frame structure.

A side effect: in PRP-1, the sequence numbers a receiver sees from one sender aren’t contiguous any more. The sender’s single counter is shared across all destinations. That’s why PRP-1 doesn’t rely on an unbroken sequence and ages out table entries by time instead.

Duplicate discard: specified vs open

PRP-0 specifies the algorithm. Each LAN keeps a drop window bounded by the next expected sequence number. The window grows, shrinks and resets as frames arrive on each LAN. The maximum window is 32 768. The standard admits the method can be fooled, for example when a node fails and recovers, or a damaged LAN is reconnected after a long time. In those cases it lets duplicates through rather than lose a frame.

PRP-1 stops specifying the algorithm. Hash tables, node tables, FIFOs or sequence tracking are all allowed. The only hard rules: never discard a legitimate frame, tolerate the occasional duplicate, and forget entries after EntryForgetTime (400 ms by default). A rebooting node must stay silent for a minimum time, NodeRebootInterval, so that every receiver has flushed its old sequence numbers before it starts again.

The standard also gives the reasoning behind the timing. The delay skew between the two copies is a network property, estimated by the designer from the number of bridges and the traffic, with 12 ms as an example. The time before a sequence number can repeat is much longer. The standard gives about 13 s as an example for an IEC 61850-9-2 merging unit sending sampled values at 4.8 kHz. As long as an entry lives longer than the worst skew and shorter than the repeat time, the table works.

Duplicate Accept: from operating mode to test mode

Both versions have two modes: Duplicate Discard and Duplicate Accept. In Duplicate Accept, the sender sends plain frames without a trailer on both LANs and the receiver passes both copies up. The upper layers deal with the duplicates. TCP drops them, and many cyclic protocols only care about the latest value.

In PRP-0, Duplicate Accept is a normal operating mode. A node announces it in its supervision frames with TLV type 21. Type 20 means Duplicate Discard.

In PRP-1, Duplicate Accept is for testing only. It’s there to check that duplicates really arrive on both LANs. The supervision frame still uses types 20 and 21, but a PRP-1 network in service runs Duplicate Discard.

If a device’s configuration offers “duplicate accept” as a production setting, it was probably designed to PRP-0 thinking. Check it.

Supervision frames

Every doubly attached node sends a supervision frame on both LANs at a regular interval, LifeCheckInterval, 2 000 ms by default. Receivers use these to build their node tables: who is a DANP, who is single-attached on LAN A or LAN B, and which mode each node runs. If a node stops sending supervision frames for NodeForgetTime (60 000 ms by default) but traffic from it still arrives on one LAN only, it’s reclassified as a single-attached node on that LAN.

Both versions send to the same multicast address range, 01-15-4E-00-01-XX, with XX set to 00 by default. Both use EtherType 0x88FB. The contents differ:

Field	PRP-0	PRP-1
Version	PRP_Ver = 0	SupVersion = 1, with a SupPath field (reserved, 0) and a SupSequenceNumber
Node identity	MacAddressA and MacAddressB, which may differ	One MacAddress used by both ports
RedBox information	Second TLV always present, zeroed if not a RedBox	Second TLV only present for a RedBox
End of TLVs	No closing TLV	Closing TLV0 (type 0, length 0)
Trailer	4-octet RCT, LSDU size always 46	6-octet RCT ending in 0x88FB
Frame size	64 / 68 octets	70 / 74 octets

Both versions carry the same compatibility rule. A node built for version X reads newer versions as if they were version X, ignoring added fields, and reads older versions exactly as written. In practice, the two frame layouts are different enough that you shouldn’t count on a PRP-0 node building a correct node table from PRP-1 supervision frames, or the other way round.

Frame size

PRP adds bytes to every frame, so maximum frame size matters.

PRP-0 chose to stay inside the IEEE 802.3 limits. A node in Duplicate Discard mode limits its payload to 1 496 octets, so that the frame plus a four-octet trailer stays legal.

PRP-1 goes the other way. It expects every component in both LANs to carry frames up to the IEEE 802.3 maximum plus the 6-octet trailer: 1 528 octets. It notes that most Ethernet controllers handle 1 528 octets and that most bridges forward frames up to 1 536 octets.

On site this means: check the maximum frame size setting on every switch in both LANs. A switch limited to 1 522 octets will drop full-size frames carrying a PRP-1 trailer. Small frames go through, so pings and SCADA polls look fine while large transfers, file uploads or full-size GOOSE and MMS messages fail. That’s a classic “it works, mostly” fault.

PRP-1 also pads short frames further: to 70 octets without a VLAN tag, 74 with one. That way the frame stays at least 64 octets even if a RedBox strips the trailer or a switch removes the tag, and the trailer always sits right before the FCS.

What happens if you mix PRP-0 and PRP-1

The standard doesn’t describe a mixed network. Reading the two specs together, though, the outcome is predictable.

A PRP-1 node receiving from a PRP-0 sender. The PRP-0 trailer has no 0x88FB suffix. The PRP-1 receiver doesn’t see a duplicate candidate, so it treats each copy as an ordinary frame and passes both up.

A PRP-0 node receiving from a PRP-1 sender. The last 12 bits of a PRP-1 frame are the low bits of the suffix (0x8FB, which is 2 299). That never matches a real payload size, so the PRP-0 receiver doesn’t see a duplicate candidate either. Both copies go up.

So traffic still flows, and a single LAN failure still doesn’t stop it. But you lose duplicate discard. Every frame arrives twice at the application. You also lose the redundancy supervision that depends on it: the wrong-LAN counters, the per-LAN statistics and a trustworthy node table.

Some applications don’t mind. Others do. Event-driven protocols and anything that counts messages may misbehave. Don’t plan a mixed network on paper. If you must run one during a staged upgrade, test the real devices and the real application traffic first.

How to tell which version a device speaks

Read the documentation. Look for the edition: “IEC 62439-3:2012” or later means PRP-1. “IEC 62439:2008” or “IEC 62439-3:2010” means PRP-0. Many relay and switch manuals say “PRP-0” or “PRP-1” outright, and some devices offer both as a setting.

Capture a frame. Look at the last bytes before the FCS on any frame from the device in Duplicate Discard mode:

• If the frame ends with 88 FB, it’s PRP-1.
• If it doesn’t, and the 12 bits before the end equal the payload size, it’s PRP-0.

Capture a supervision frame. Filter on destination 01-15-4E-00-01-00. In PRP-1 you’ll find a version of 1 and a closing TLV. In PRP-0, the version is 0 and both port MAC addresses appear in the frame.

If you need to set up a capture point on a PRP network, see the PRP/HSR network connection guide.

Practical checklist

Before you commission a PRP network:

1. One version for the whole network. Confirm every DANP, every RedBox and every PRP-aware switch runs PRP-1, unless you have a documented reason to keep PRP-0.
2. Check the old devices. Relays and RTUs from around 2008–2012 may only support PRP-0. Look for a firmware update or a setting before you assume.
3. Check the RedBoxes. A PRP–HSR RedBox only makes sense with PRP-1, since PRP-0 has no defined interconnection with HSR. See RedBox and QuadBox.
4. Set the maximum frame size on every switch in both LANs to at least 1 528 octets for PRP-1.
5. Use Duplicate Discard in service. Duplicate Accept is a test mode in PRP-1.
6. Keep the two LANs fully separate. No bridging node and no shared switch between LAN A and LAN B. That rule is the same in every edition.
7. Check the supervision timers. All DANPs should use the same LifeCheckInterval. If you change the defaults, change them everywhere.
8. Plan clocks separately. If you run PTP over PRP, see PTP on PRP/HSR networks and the IEC/IEEE 61850-9-3 power profile. The clock rules changed between 2012 and 2016.

FAQ