High-Availability Seamless Redundancy (HSR) and Parallel Redundancy Protocol (PRP)

High-Availability Seamless Redundancy (HSR) and Parallel Redundancy Protocol (PRP), defined in IEC 62439-3, provides seamless failover on link failure. Both build on the same idea of duplicating traffic and can be coupled with each other.

The purpose of this document is to cover the basics of HSR/PRP.

For example use-cases, see:

Table of contents

Introduction

The general idea of HSR and PRP is duplicating traffic and sending over different paths in the network. At the point where they meet up again, only the first frame to arrive will be forwarded. A duplicate discard algorithm eliminates the second copy to ensure no frame is delivered twice.

Each frame is uniquely identified by a combination of a sequence number (a 16-bit unsigned integer) and its source MAC address. The sequence number wraps around after reaching the maximum value. To avoid identifying different frames as the same, EntryForgetTime specifies how long (milliseconds) it remembers the identity of a frame. When the entry expires, a new frame with the same identity counts as a new frame, not as a duplicate of the earlier one.

In the event of a link failure, one copy will still reach its destination.

Within HSR and PRP networks different types of devices are called by specific names according to how they can be attached to a network.

Doubly Attached Nodes or DANs are called as such as they are devices that support HSR/PRP through at least two Ethernet connections. Usually DANs are referred to by the protocol they run, Doubly Attached Node HSR (DANH) or Doubly Attached Node PRP (DANP).

Singly Attached Nodes or SANs are devices that are restricted to a single Ethernet connection. In this case, a RedBox can connect the SAN to an HSR/PRP network, allowing the SAN to appear as a DANH/DANP to the rest of the network.

Redundancy Box (RedBox)

A RedBox has at least 3 Ethernet ports. Two of these are assigned as redundancy ports, called port A and port B, that create and discard duplicate traffic. The third port is the interlink. It is possible to have multiple ports as interlinks provided they are all configured the same. The redundant ports operate either in HSR mode or PRP mode. The interlink operates in one of three modes: SAN, HSR, or PRP. The modes a RedBox as a whole can support are HSR-SAN, PRP-SAN, HSR-PRP, and HSR-HSR.

  • HSR-SAN: Connects a SAN to an HSR ring.
  • PRP-SAN: Connects a SAN to two PRP LANs.
  • HSR-PRP: Connects a PRP LAN to an HSR ring.
  • HSR-HSR: Connects another HSR network to an HSR ring (can be used to make a QuadBox)

High-Availability Seamless Redundancy (HSR)

HSR is a ring protocol. All network traffic in the ring has an HSR tag with the Ethertype 0x892f. If a frame contains a VLAN tag, then the HSR tag comes after the VLAN tag.

The HSR tag contains:

  • 4-bit path identifier (PathId)
  • 12-bit frame size (LSDUsize)
  • 16-bit sequence number

The device injecting a frame into the ring gives it an HSR tag with a sequence number based on the source MAC and sends the frame to both ring ports. Upon reaching a DANH that’s the unique destination (unicast), or a RedBox with the destination behind it, it stops traversing the ring. Multicast and broadcast always traverse the entire ring, and the device that initially injected the frame into the ring discards it after a full lap.

The PathId and LSDUsize fields aren’t relevant in the context of a setup with only HSR. PathId is 0. LSDUsize is the size of the frame, excluding the DMAC, SMAC, and VLAN tags. They only become relevant in PRP and when coupling HSR with PRP.

Figure 1 shows a minimal HSR setup.

            +---------+              
            |         |              
            |   SAN   |              
            |         |              
            +----+----+              
                 |                   
                 |                   
            +----I----+              
            |         |              
            | RedBox  |              
      +-----A HSR-SAN B------+       
      |     |         |      |       
      |     +---------+      |       
      |                      |       
      |                      |       
      |     +---------+      |       
      |     |         |      |       
      +-----A RedBox  B------+       
            | HSR-SAN |              
            |         |              
            +----I----+              
                 |                   
                 |                   
            +----+----+              
            |         |              
            |   SAN   |              
            |         |              
            +---------+

Figure 1: Two SAN devices connected redundantly via two HSR-SAN RedBoxes.

Parallel Redundancy Protocol (PRP)

Unlike HSR, PRP isn’t a ring protocol. Instead, it duplicates the traffic onto two different LANs, named LAN A and LAN B. These two LANs must match up with the A and B ports of the DANP/RedBox on each side. The PRP tag looks similar to the HSR tag but in the place of PathId there is instead the 4-bit field LanId. It has the value 0xA for the frame sent on LAN A, and 0xB for LAN B. A PRP device accepts frames even if the LanId field doesn’t match with the receiving port, but it will increment an error counter. It also accepts frames without a PRP tag, allowing for many other SANs within each LAN.

Instead of a header like HSR, the PRP tag is a trailer on the frame, placed right before the Ethernet checksum. To not confuse the payload of a non-PRP frame with the trailer the LSDUsize acts as an extra checksum to verify that it’s a PRP frame. There may still be cases of a correctly formed PRP tag appearing in the payload of a frame, but the checksum makes it less likely. For this reason, frames are still delivered even if the LanId doesn’t match the port. An error counter is incremented to indicate that it happened. The A and B ports have no significance in an HSR ring.

The topology in Figure 1 can also be used for PRP-SAN mode, assuming both A ports are connected to each other (LAN A), and same for B ports.

HSR-PRP coupling

The mode HSR-PRP connects a PRP LAN to an HSR ring. The interlink port connects to the PRP LAN and is set to A or B depending on which LAN it is. Along with the LanId, it has a NetId to indicate which PRP network it came from. Together these two fields form the PathId field of the HSR tag. The least significant bit is the LanId and the remaining three bits are the NetId. The value of NetId must be in the range 1-6. A RedBox receiving a PRP frame on the interlink forwards it to the HSR ring and sets the PathId field based on the settings on the interlink port to indicate where it came from. This prevents reinjection into the other PRP LAN.

Supervision frames and ring status

Every HSR/PRP node sends out supervision frames (Ethertype 0x88fb) at LifeCheckInterval intervals. These frames serve two purposes.

  1. Ensuring that the redundancy is ok by checking that it gets the frames on both ports.
  2. For RedBoxes, inform other nodes what nodes it has connected on the interlink.

Alarms

HSR/PRP alarms trigger when the redundancy is broken. Configure alarms in the alarm context as a ring trigger. See Alarm. If the devices stops seeing supervision traffic from a node on both links, the alarm triggers.

HSR/PRP with PTP

Precision Time Protocol (PTP) will behave differently when used in conjunction with HSR/PTP.

PTP messages are still duplicated over HSR/PRP networks, except peer delay messages. They are link-local and use the destination MAC address 01:80:C2:00:00:0E. They measure the time delay to the link partner to allow compensation for ingress, egress, and cable delay.

Despite this, they still carry an HSR tag. All PTP synchronization messages are defined to have the same length, as to not introduce differences in travel time due to frame length. Since the other PTP messages need the HSR tag to traverse the ring it makes sense that peer delays also have it.

Unlike normal HSR/PRP traffic, the PTP receivers do not use the first copy to arrive. It selects one port to listen on, and swaps over to the other when messages cease to arrive on the selected side. Always taking the first to arrive may result in additional jitter, as the residence time will vary between the two paths.

The redundancy ports’ PTP port states are coupled. For a TC they are either both MASTER, transmitting Sync information received on the interlink, or they are SLAVE/PASSIVE_SLAVE (one each), forwarding Sync information from the SLAVE port to interlink. In an HSR ring, regardless of port state and mode (TC/BC), all Sync messages are forwarded within the ring according to TC operation and are discarded by the device that injected it.

Syntax HSR/PRP Configuration

type <hsr|prp|hsr-prp>
Select type of HSR/PRP instance (HSR-SAN, PRP-SAN, HSR-PRP). Must be set before any other options.
[no] enable
Enable/Disable the instance.
[no] supervision-frame
Enable/Disable supervision frames
mode <H|N>

Select the operating mode for HSR. Only applicable for type hsr.

H
[HSR-tagged mode] default operational mode where the unit inserts HSR tag and forwards traffic.
N
[No forwarding] operational mode, just like mode H, except that the unit does not forward traffic from port to port. Intended for testing purposes only.

prp-id <1..6>

NetId of the PRP network attached to the interlink. Only applicable for type hsr-prp.

RedBoxes connected to the same PRP network should have the same NetId. The HSR tag carries this value, which prevents frames from LAN A from being reinjected into its corresponding LAN B, and vice versa.

lan-id <A|B>

LanId of the PRP network attached to the interlink. Only applicable for type hsr-prp.

The HSR tag of frames originating from the interlink contains which LAN it is.

When both HSR/PRP and PTP are configured, PTP automatically assumes HSR/PRP mode for the redundancy ports.

HSR/PRP Status Commands and Explanations

redbox:/#> show hsr-prp
HSR instance id 1                                                            
Enabled                     : YES
Type                        : HSR
HSR mode                    : H
Port A                      : ethA
Port B                      : ethB
Supervision frames          : Enabled
Life check interval         : 2 s
Entry forget time           : 6 (640 ms)
Node reboot interval        : 500 ms
Node forget time            : 64 s
Proxy node table forget time: 64 s
Multicast octet             : 00
Redundancy status           : Ok
CntError A                  : 0
CntError B                  : 0
CntReceived A               : 0
CntReceived B               : 0
CntSent A                   : 0
CntSent B                   : 0
CntWrongLan A               : 0
CntWrongLan B               : 0
CntDuplicate A              : 0
CntDuplicate B              : 0

STATUS
Node Table          Type      Age (s):  A  |  B  |  I
50:00:84:65:9d:2a   REDBOXH             0  |  0  |  -
00:11:b4:53:2f:80   REDBOXP             1  |  1  |  1
38:f3:ab:96:ec:12   VDANP               1  |  1  |  1
00:07:7c:6e:34:ca   VDANP               1  |  1  |  1
00:11:b4:53:2d:00   REDBOXP             0  |  0  |  -
00:07:7c:6e:34:c8   VDANP               0  |  0  |  -
Proxy Nodes
22:11:b4:02:03:01
00:07:7c:6e:34:c7
00:07:7c:6e:34:c0

This view contains the settings and statistics of the HSR/PRP instance.

Redundancy status indicates if the redundancy is working or not. Possible output values are Ok and Broken.

CntError represents frames dropped due to, for example, bad Ethernet checksum. CntReceived is the amount of valid frames received. CntSent is the amount of frames sent. CntWrongLan is only valid for PRP and HSR-PRP and shows the number of frames received that contain the wrong LAN in the PRP tag. If the network is misconfigured this counter will rapidly increase. Occasional increases could mean a non-PRP frame where the payload happened to look like a PRP tag. CntDuplicate is the amount of frames detected as copies of frames received earlier.

Proxy Nodes shows the nodes present on the interlink port. It exists for advertising to other nodes which ones are reachable through the HSR/PRP network. In HSR-PRP mode, the Proxy Nodes list only contain nodes that are not advertised through supervision frames (i.e. if a node is in the Node Table it will not also show up as a proxy node).

Node Table shows the nodes advertised by other RedBoxes/DANH/DANP in the network through HSR/PRP supervision frames. The proxy nodes of other devices appears in this list.