What Happens When the Network Breaks? RSTP, MRP, HSR, and PRP
An Ethernet cable has been cut. What happens now?
In an office network, the answer may often be, “there will be a brief interruption, and the network will find a new path.” But if the same network carries protection or control information in a substation, even the loss of a few packets may need separate consideration. This is where four abbreviations enter the picture: RSTP, MRP, HSR, and PRP.
Their names may look similar, but they do not solve the problem in the same way. RSTP and MRP rearrange the communication path after detecting a failure. HSR and PRP rely on sending a backup copy before the failure occurs.
The main subject of this article is not the substation itself. It is continuous-communication design*. A substation is simply a useful example because it lets us see the physical significance of the difference.
Keep this distinction in mind
The four mechanisms can be remembered in one short list:
- RSTP:* Builds a loop-free active path and reconverges the network by changing port roles after a failure.
- MRP:* Manages an industrial Ethernet ring and rearranges the ring over the alternative path after a failure.
- HSR:* In the common ring model, sends the same frame in both directions.
- PRP:* Sends the same frame over two separate Ethernet networks.
For the first two, the key word is recovery*. For the other two, the second copy is already in transit.
RSTP: holding some paths in reserve to keep the network usable
If Ethernet switches are connected in arbitrary loops, frames can circulate and multiply inside the network. Rapid Spanning Tree Protocol creates a loop-free active topology in a bridged network. Some ports forward traffic, while others that could provide an alternative path remain in a non-forwarding role.
Think of the corridors in a building. If every door is left open at the same time, people may walk around in circles. RSTP decides which doors are used. If an active corridor closes, the role of a waiting path changes and the network is rearranged.
The important point is that RSTP is designed for rapid reconfiguration, but it is still a post-failure reconfiguration* approach. The actual interruption depends on the topology, how the link failure is detected, port and bridge roles, configuration, and interoperability with legacy STP devices. The mere presence of RSTP therefore does not guarantee a particular recovery time.
RSTP is intended for general-purpose bridged networks. It is not limited to rings; it can create a loop-free active structure across different physical topologies.
MRP: controlled recovery for an industrial ring
Media Redundancy Protocol is a ring-based recovery protocol defined in IEC 62439-2. The ring is supervised by a media redundancy manager. When a single link or switch failure is detected, the ring is rearranged so that communication can continue in the other direction.
RSTP and MRP can be placed in the same broad family in this respect: both change the topology after a failure. MRP, however, offers a more specialized model for an industrial Ethernet ring and a deterministic response target for a single failure. RSTP is a more general bridging solution.
That distinction is more useful than asking which one is simply “better.” Is the design a ring or a more general mesh? What recovery time is required? Do the selected switches genuinely support the same MRP profile? The answer comes from these conditions, not from the protocol name alone.
HSR: using both directions from the start
High-availability Seamless Redundancy is covered by IEC 62439-3. In the common ring model, an HSR node sends the same frame from both ports and in both directions around the ring. The first valid copy to reach the destination is delivered to the upper layer; the matching copy that arrives later is discarded.
When a link breaks, the network does not wait to decide which path to open. The second copy is already travelling in the other direction. IEC 62439-3 describes this behavior as seamless switchover with zero recovery time.
There is a small but important trap here: zero recovery time does not mean zero end-to-end latency.* The frame still passes through devices, may be queued, and must be processed by the application. The claim is that a new path does not have to be established after a single network-element failure.
An HSR ring is not made only of switches. An HSR-capable relay, RTU, or another IED may act as a transit node. Transit nodes inside the ring must, however, implement the required HSR functions. The standard also covers meshes built with multiport nodes in addition to rings of two-port nodes; this article uses the ring because it is the easiest model to visualize.
PRP: entrusting the same message to two separate networks
Parallel Redundancy Protocol is also covered by IEC 62439-3. A PRP node sends the same information simultaneously over two separate Ethernet networks, referred to as LAN A and LAN B. The receiver uses the first valid copy and discards the other as duplicate traffic.
HSR and PRP share the same central idea: the second copy is sent before a failure. The environments followed by those copies are different. With HSR, the copies travel in opposite directions through the same ring structure. With PRP, they travel through two separate LANs.
PRP is therefore not only a protocol choice; it is also an infrastructure decision. Two networks may mean more switches, cables, ports, power supplies, and maintenance discipline. In return, they make it possible to separate the failure domains of the two paths more strongly. Whether that advantage is realized depends on how the LANs are actually separated with respect to shared components and common-cause failures.
Putting all four side by side
| Mechanism | Typical topology | Behavior during a failure | Simplest mental model |
|---|---|---|---|
| RSTP | Bridged ring or mesh | Changes port roles and reconverges the active topology | Opens a waiting path after the failure |
| MRP | Managed industrial Ethernet ring | Detects the failure and rearranges the ring for the alternative path | Recovers the ring after the failure |
| HSR | Commonly, a ring of two-port nodes | Sends the frame in both directions in advance and discards the duplicate | Uses both directions of the same ring at once |
| PRP | Two separate Ethernet LANs | Sends the frame over both LANs in advance and discards the duplicate | Gives the same message to two separate networks |
This table is not a product guarantee. The supported standard revision, firmware, port roles, capacity, and interoperability must be verified against vendor documentation.
Why does this matter in a substation?
Now let us apply this general distinction to a substation.
A protection relay evaluates quantities such as current and voltage and may decide to open a circuit breaker when defined conditions occur. We should not assume that this chain always depends on Ethernet. Measurement and trip circuits may be fully hardwired. In another design, measurements may be transported as Sampled Values, while status or trip information may be carried through GOOSE.
A simple mental model in the IEC 61850 context is:
- GOOSE* can carry event and state information such as trips, interlocks, or state changes.
- Sampled Values* defines the mapping used to transport sampled process values such as current and voltage over Ethernet.
- MMS-based communication* can carry functions such as supervision, reporting, and control, each with different timing expectations.
This does not mean that every Ethernet packet in a substation must be transported without interruption. We first need to understand which physical or operational function a message supports. A brief interruption to engineering access and an interruption to communication used in a protection decision do not carry the same risk.
The central design question is: Can this function wait for the network to recover?* If the answer is yes, a recovery-based mechanism such as RSTP or MRP may be sufficient. If the answer is no, an approach such as HSR or PRP, which sends the second copy in advance, can be evaluated.
Where do SAN, DAN, and RedBox come from?
Several more abbreviations appear when discussing HSR and PRP:
- DANH* is a doubly attached node that implements HSR.
- DANP* is a doubly attached node connected to both PRP LANs.
- SAN* is a singly attached node that does not natively implement the redundancy protocol.
- RedBox* performs the necessary redundancy adaptation between a SAN and an HSR or PRP domain.
- VDAN* describes a SAN behind a RedBox being represented to the redundant network as a virtual doubly attached node.
A SAN may connect without redundancy to only one of the PRP networks. A RedBox is required if the same device is to participate redundantly in both PRP LANs. In an HSR ring, a SAN without HSR capability cannot act directly as a transit node in the ring.
“Seamless” does not mean forgetting the failure
HSR and PRP can hide a single-path failure from the application. That benefit has an operational consequence: if the loss of the first path goes unnoticed because the application continues to work, the system may now be operating without redundancy.
Application availability and redundancy health should therefore be monitored separately. The following questions are useful during design and acceptance testing:
- Which function depends on this network, and how much interruption can it tolerate?
- How quickly, and where, does a single-path failure become visible?
- Has a second failure been tested while one path is unavailable for maintenance?
- Could shared power, a cable route, or a device affect both paths?
- Have duplicated traffic and multicast load been included in the capacity calculation?
- Does the monitoring sensor actually see both PRP LANs or the necessary segments of the HSR ring?
Packet capture requires care as well. Seeing two copies of the same frame is not automatically evidence of a loop or an attack. Conversely, a sensor that sees only one LAN cannot determine the health of the second path. The capture position and duplicate-discard behavior should be recorded with the analysis result.
Redundancy does not provide cybersecurity
RSTP and MRP manage topology; HSR and PRP duplicate frames. By themselves, these mechanisms do not authenticate the sender, provide message integrity, or encrypt content.
The security of IEC 61850-based communication must be handled separately. IEC 62351-6 defines messages, procedures, and algorithms for securing protocols derived from IEC 61850. The security profile and operating mode actually supported by the selected product must also be verified.
Conclusion
The subject is simpler than memorizing four abbreviations:
RSTP and MRP recover the network after a failure. HSR and PRP send the backup copy before the failure.
Substation communication is a strong example that makes this distinction visible, but the decision method is more general. First, identify the function of the information being carried and its acceptable interruption. Then select the redundancy approach by considering topology, device support, failure domains, monitoring, and cost.
Evidence boundary
The basic definitions of RSTP, MRP, HSR, PRP, and the IEC 61850 mappings were verified* against official IEEE/IEC publication records and a vendor implementation manual. The operational guidance about capture position and the effect of duplicate discard on visibility is inferred* from those definitions.
Recovery time and protection impact were not measured on a particular site, product, or firmware; these remain open* validation areas. This article is therefore neither a product conformity statement nor a ready-made design prescription.
Sources
- IEEE 802.1Q-2022 — Bridges and Bridged Networks
- IEEE 802.1 Working Group — Rapid Reconfiguration of Spanning Tree
- IEC 62439-2:2021 — Media Redundancy Protocol (MRP)
- IEC 62439-3:2021 — Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)
- IEC 61850-5:2013+AMD1:2022 — Communication requirements for functions and device models
- IEC 61850-8-1:2011 — Mappings to MMS and ISO/IEC 8802-3
- IEC 61850-9-2:2011 — Sampled values over ISO/IEC 8802-3
- IEC 62351-6:2020 — Security for IEC 61850
- Siemens — Reyrolle 7SR5 Communication Protocol Manual, Edition 08/2024