ExpectedSeqACurrentSeqA c es dropWindow keepBdropB keepB LAN_A LAN_B Figure 9 – PRP drop window on LAN_A After checking the correct sequence number, the receiver decides whether to disc
Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 60050-191, as well as in IEC 62439-1, apply, in addition to the following
3.1.1 extended frame frame that has been extended by a Redundancy Control Trailer
3.1.2 interlink link that connects two network hierarchies
RedBox device allowing to attach single attached nodes to a redundant network
A quadruple port device connects two peer High-Speed Ring (HSR) networks, functioning as an HSR node in each ring This device effectively filters traffic and facilitates the forwarding of data between the two rings.
HSR frame frame that carries the HSR EtherType
Abbreviations and acronyms
For the purposes of this document, the following abbreviations and acronyms apply, in addition to those given in IEC 62439-1:
DANH Double attached node implementing HSR
DANP Double attached node implementing PRP
ICMP Internet Control Message Protocol (part of the Internet protocol suite)
VDAN Virtual Doubly Attached Node (SAN as visible through a RedBox)
Conventions
This document follows the conventions defined in IEC 62439-1
PRP principle of operation
PRP network topology
This redundancy protocol implements redundancy in the devices, through doubly attached nodes operating according to PRP (DANPs)
A DANP connects two independent LANs, LAN_A and LAN_B, that share a similar topology and operate in parallel A source DANP transmits identical frames across both LANs, while a destination DANP receives these frames within a specified timeframe, processes the first frame, and discards any duplicates.
Figure 1 illustrates a redundant network made up of two switched Local Area Networks (LANs) that can adopt various topologies, such as tree, ring, or mesh configurations.
RedBox switched local area network (ring) LAN_A
Figure 1 – PRP example of general redundant network
The two LANs share the same MAC-LLC protocol but may vary in performance and topology Additionally, transmission delays can differ, particularly if one network reconfigures using RSTP to address an internal failure.
The two LANs follow configuration rules that allow the network management protocols such as Address Resolution Protocol (ARP) to operate correctly
The two LANs operate independently without any connection, ensuring fail-independence However, redundancy may be compromised by single points of failure, like a shared power supply or a direct link that could disrupt both networks This document offers installation guidelines to help achieve and maintain fail-independence.
PRP LANs with linear or bus topology
As an example of a simpler configuration,
Figure 2 draws a PRP network as two LANs in linear topology, which may also be a bus topology
DANP DANPDANP DANPDANP DANPDANP DANPDANP DANPDANP
Figure 2 – PRP example of redundant network as two LANs (bus topology)
PRP LANs with ring topology
The two LANs can have a ring topology, as Figure 3 shows switch switch
. switch switch switch switch switch switch
Figure 3 – PRP example of redundant ring with SANs and DANPs
DANP node structure
Each node features two parallel ports connected to the upper layers of the communication stack via the Link Redundancy Entity (LRE), as illustrated in Figure 4.
Tx Rx port A Link Redundancy Entity network layer hard UDP real-time stack
Tx Rx port B network adapters transceivers upper layers
Tx Rx port A Link Redundancy Entity network layer hard UDP real-time stack
Figure 4 – PRP with two DANPs communicating
The Link Redundancy Entity (LRE) performs two key functions: it manages duplicate data and oversees redundancy This layer offers an interface to its upper layers that is identical to that of a non-redundant network adapter.
When receiving a frame from the node’s upper layers, the LRE sends the frame through both its ports at nearly the same time
The two frames transit through the two LANs with different delays, ideally they arrive at the same time at the destination node
When receiving frames from the network, the LRE forwards the first received frame of a pair to the node’s upper layers and discards the duplicate frame (if it arrives)
To manage redundancy, the LRE appends a Redundancy Check Trailer (RCT) with a sequence number to the frames it transmits, allowing it to monitor duplicates Additionally, the LRE regularly sends PRP_Supervision frames and assesses the PRP_Supervision frames from other DANPs.
PRP attachment of singly attached nodes
Singly attached nodes (SANs) can be attached in two ways:
SANs are limited to direct connections with a single LAN, allowing communication solely with other SANs within that same network For example, SAN A1 can interact with SAN A2, but cannot connect with SAN B1 or SAN B2 However, SANs are capable of communicating with all DANPs.
SANs can be connected to both LANs via a RedBox (redundancy box), as illustrated in Figure 1 for R1 and R2 This setup allows for communication between all SANs, enabling interactions such as between SAN A1 and SAN R1.
NOTE SANs do not need to be aware of PRP, they can be off-the-shelf computers
In certain applications, only devices critical for availability, such as operator workplaces, require double attachment, while most devices are Storage Area Networks (SANs) Utilizing the basic infrastructure of Parallel Redundancy Protocol (PRP), a Dual Attached Node Protocol (DANP) can connect to two different switches within the same Local Area Network (LAN), like a ring, and employ protocols distinct from PRP for network reconfiguration during failures The DANP functions as a switch element in accordance with IEEE 802.1D, potentially implementing protocols such as the Media Redundancy Protocol (MRP) or Rapid Spanning Tree Protocol (RSTP), with the option to restrict traffic forwarding between ports These capabilities are optional and not explicitly detailed in the International Standard, with the supported mode outlined in the Protocol Implementation Conformance Statement (PICS).
Compatibility between singly and doubly attached nodes
Singly attached nodes (SAN), such as maintenance laptops or printers, can connect to any LAN, but they cannot communicate directly with SANs on different LANs Switches function as SANs and are unaware of PRP redundancy, leading to the generation of traffic that SANs can interpret SANs are designed to ignore the RCT in frames, as they cannot differentiate it from ISO/IEC 8802-3 (IEEE 802.3) padding In contrast, DANPs can comprehend the traffic from SANs since they do not include an RCT, forwarding only one frame to their upper layers, as SAN traffic operates within a single LAN If a DANP cannot confirm that a remote device is another DANP, it will treat it as a SAN.
Network management
A node shares the same MAC address across both ports, with a single set of IP addresses assigned, ensuring redundancy is seamless for upper layers This configuration allows the Address Resolution Protocol (ARP) to function similarly to a Storage Area Network (SAN) Unlike doubly attached devices, switches in a Local Area Network (LAN) possess unique IP addresses A Dynamic Address Network Protocol (DANP) is the preferred network management tool, enabling access to nodes and switches as if they are part of a unified network Furthermore, network management within a DANP can effectively monitor SANs connected to any LAN.
Certain applications necessitate distinct MAC addresses for redundant ports, which may differ from the node's default MAC address While the International Standard does not specify the address substitution mechanisms, the fundamental protocol and frame format are designed to accommodate such extensions Nodes that enable MAC address substitution are marked as supporting PICS_SUBS.
Implication on configuration
To ensure effective communication between publishers and subscribers, it is crucial to select a cyclic time-critical data period that accounts for the significant time difference between frames arriving from two ports This selection must consider the latency variations, specifically the worst-case and best-case scenarios.
Transition to non-redundant networks
The RedBox facilitates duplicate rejection by acting as a transition point between a SAN and multiple LANs, as illustrated in Figure 5 It emulates the SANs it connects to, referred to as virtual DANs (VDAs), and sends out supervision frames while including its own information Additionally, the RedBox functions as a DANP with a dedicated IP address for management, and it is capable of executing application functions.
Tx A Rx Tx Rx transceivers
LAN_A LAN_B switching logic non-redundant network
Tx Rx singly attached nodes
Figure 5 – PRP RedBox, transition from single to double LAN
Duplicate handling
Since a DANP receives the same frame over both adapters, when both are operational, it should keep one and ignore the duplicate
There are two approaches to managing duplicates in data transmission: the first is duplicate accept, where the sender LRE transmits original frames and the receiver LRE forwards all received frames to higher protocol layers; the second is duplicate discard, where the sender LRE adds a redundancy control trailer to each frame, allowing the receiver LRE to forward only the first frame of a duplicate pair to upper layers while filtering out the rest.
This method does not eliminate duplicates at the link layer, as the sender LRE transmits the same frame over both LANs, similar to a non-redundant scenario The receiver’s LRE forwards both frames of a pair to its upper layers, operating under the assumption that robust network protocols and applications can handle duplicates Notably, IEEE 802.1D explicitly acknowledges that it cannot guarantee the absence of duplicates.
The internet stack includes a resilient network layer with both UDP and TCP transport layers, where TCP effectively discards duplicate frames, while UDP, being connectionless and unacknowledged, requires applications to manage duplicates UDP frames are considered idempotent, meaning that sending them multiple times yields the same outcome as sending them once Additionally, administrative protocols like ICMP and ARP are unaffected by duplicates due to their own sequence numbering systems.
Real-time stacks that function on the publisher-subscriber principle effectively manage duplicates by retaining only the most recent value This approach enhances robustness, as a sample lost on one LAN is typically received from another LAN.
Therefore, one can assume that handling of duplicates is taken care of by the usual network protocols, but one has to check if each application complies with these assumptions
The straightforward duplicate acceptance method lacks effective redundancy supervision, as it fails to monitor the accurate reception of both frames To identify the first frame of a duplicate pair, the receiver would require hash tables to store the CRC and length of each frame as a hash code Although this redundancy supervision method is not outlined in the International Standard, it is not explicitly prohibited.
4.1.10.3 Duplicate discard in the link layer
It is advantageous to discard duplicates already at the link layer
When multiple LANs are connected, the processor encounters double the interrupt requests compared to a single LAN connection To alleviate the load on the application processor, the LRE can implement Duplicate Discard, potentially utilizing a separate pre-processor or an advanced Ethernet controller This approach not only enhances processing efficiency but also improves redundancy monitoring.
The duplicate discard protocol incorporates a four-octet field known as the Redundancy Control Trailer (RCT) into each frame received from the upper layers, as illustrated in Figure 6 The RCT includes key parameters: a 16-bit sequence number (SequenceNr), a 4-bit LAN identifier (Lan), and a 12-bit frame size (LSDU_size).
Redundancy Control Trailer frame without redundancy control
Figure 6 – PRP frame extended by an RCT
When a LRE transmits a frame to a specific destination, it increments the sequence number associated with that destination and sends nearly identical frames across both LANs The receiving LRE is able to identify duplicates using the RCT.
This method acknowledges the presence of Storage Area Networks (SANs) on the network, which may lead to frames being mistakenly identified as duplicates due to identical trailing fields, sequence numbers, and sizes However, since SANs operate solely within one Local Area Network (LAN), the source of each frame will differ, ensuring that frames from SANs are never discarded.
The field LAN can have two values: 1 010, which signifies that the frame was transmitted over LAN_A, and 1 011, indicating transmission over LAN_B This functionality aids in identifying installation errors.
To help the receiver LRE differentiate between frames from nodes adhering to the PRP and those that are non-redundant, the sender LRE includes the length of the link service data unit (LSDU) in octets within a 12-bit field appended to the frame.
EXAMPLE If the frame carries a 100-octets LSDU, the size field equals LSDU+RCT: 104 = 100 + 4
In VLANs, frame VLAN tags can be added or removed while passing through a switch To ensure the length field remains unaffected by VLAN tagging, only the LSDU and RCT are taken into account for the LSDU_size, as illustrated in Figure 7.
Figure 7 – PRP VLAN-tagged frame extended by an RCT
The receiver scans frames from the end, checking if the 12 bits preceding the end match the LSDU size and if the LAN identifier aligns with its own If both conditions are met, the frame may be rejected.
Short frames require padding to achieve the minimum frame size of 64 octets, prompting the sender to include this padding for faster scanning, as illustrated in Figure 8.
Figure 8 – PRP constructed, padded frame closed by an RCT
A VLAN-tagged frame can traverse multiple switches that may modify VLAN tags According to the ISO/IEC 8802-3 (IEEE 802.3) standard, a minimum frame size of 68 octets is required for VLAN-tagged frames and 64 octets for untagged frames, ensuring that padding before and after the RCT is avoided Scanning from behind is recommended as a precautionary measure.
Appending the RCT could generate oversize frames that exceed the maxValidSize foreseen by ISO/IEC 8802-3 (IEEE 802.3)
To maintain compliance with IEEE 802.3:2005, the communication software in a DANP using duplicate discard is configured for a maximum payload size of 1 496 octets
Configuration check
The last 4 bits of the RCT serve as unique identifiers for LAN_A and LAN_B, represented by the codes 1 010 (“A”) and 1 011 (“B”), resulting in frames that differ by one bit and the FCS The receiver verifies the source of the frame to ensure it originates from the correct LAN but does not discard frames from the incorrect LAN, as they may still be valid However, it does increment the error counters CntErrWrongLanA or CntErrWrongLanB to indicate a potential configuration issue, allowing for quick detection of this type of permanent error.
Network supervision
The health status of each LAN and its attached devices (nodes and switches) is monitored, otherwise redundancy helps little
The receiver checks that all frames come in sequence and that frames are correctly received over both channels It maintains error counters that network management can read
All senders and receivers keep tables of nodes for communication, which log the last time a frame was received from another node, the time a multicast or broadcast frame was sent, and additional protocol details.
At the same time, these tables allow to establish connections to synchronize the sequence numbers and detect sequence gaps and missing nodes
Since the protocol is loosely connection oriented, the sequence numbers corresponding to non-existent nodes are cleaned up by a low priority task after a time NodeForgetTime
Supervision is dependent on each DANP periodically transmitting a PRP_Supervision frame, which facilitates the verification of network integrity and node presence These frames also provide information about the devices identified as DANP, their corresponding MAC addresses, and the operating modes they support, including duplicate accept or duplicate discard.
Redundancy management interface
Redundant devices and links are useless without network management supervising this redundancy and calling for maintenance actions
The LRE offers a network management interface that monitors the health of each LAN, enabling early detection of failures when error rates rise It maintains a counter for each adapter, tracking both the total number of received messages and those received with errors.
The LAN statuses appear as SNMPv1 or SNMPv2/v3 variables This allows using the same tools for managing the nodes and the switches
NOTE SNMP is part of the IP protocol suite.
PRP protocol specifications
Installation, configuration and repair guidelines
NOTE These guidelines are to be followed at installation time, they do not apply to conformance testing of the devices
The network shall consist of two LANs that have similar properties, i.e each one is able to carry the traffic that would exist in the absence of redundancy
The two LANs shall be labelled A and B and shall use cables distinctly identified
Switches in the two LANs shall have a distinct label or colour for each A or B
The layout of both LANs shall fulfil the assumption of fail-independence
All DANPs shall be configured with the same multicast address for PRP_Supervision frames All DANPs shall be configured with the same LifeCheckInterval.
MAC addresses
Both adapters A and B of a DANP shall be configured with the same MAC address
This address shall be unique in the network
SANs connected to one LAN only shall not have the same MAC address as another node within the whole network (LAN_A plus LAN_B)
When a DANP utilizes PICS_SUBS, adapter A's MAC address will be used, while adapter B can have a distinct MAC address that must be unique across the entire network, including both LAN_A and LAN_B.
NOTE Nodes supporting PICS_SUBS are expected to behave as a DANP that has the default MAC address Address substitution is not specified in this International Standard.
Multicast MAC addresses
All nodes in the network shall be configured to operate with the same multicast address for the purpose of network supervision, see 4.2.7.6.
IP addresses
The IP address(es) of any node or switch within the whole network (LAN_A plus LAN_B) shall be unique
NOTE A device may have several IP addresses
A DANP shall have the same IP address(es) when seen from either LAN_A or LAN_B
Switches on LAN_A and LAN_B are considered as SANs and shall have different IP addresses for the purpose of network management.
Nodes
Doubly attached nodes under the parallel redundancy protocol (DANP) are equipped with two identical network adapters, referred to as adapter A and adapter B These adapters can function interchangeably, especially when only one local area network (LAN) is connected, with adapter A linked to LAN_A and adapter B connected to LAN_B.
Singly Attached Nodes (SAN) have only one adapter for the purpose of this protocol and may be attached to either LAN
SANs that need to communicate with one another shall be attached to the same LAN or to both LANs through a RedBox
This subclause applies to a DANP using two LANs of similar nature
The connectors for each LAN shall be labelled distinctly as A and B
When connectors are ordered vertically, LAN_A shall be the upper connector and LAN_B the lower connector in its normal position
When arranging connectors horizontally, the left connector should be designated as LAN_A, while the right connector is identified as LAN_B, as viewed from the side where the cables or fibers are connected.
The redundant connectors shall be independently removable and insertable.
Duplicate accept mode
The sender shall send the frame it receives from its upper layers unchanged over both its adapters so that the two frames appear on the respective LANs
The receiver shall forward frames received from both adapters to the upper layers
NOTE This specification is only testable indirectly, by counting the number of frames over the MIB.
Duplicate discard mode
A node must maintain a table for each connected node (SAN or DANP) that it communicates with, using the MAC address as a key This table includes essential information for each unicast, multicast, or broadcast address, such as a 16-bit sequence number (SendSeq) for outgoing frames, and expected sequence numbers (ExpectedSeqA and ExpectedSeqB) for incoming frames from the remote node It also tracks errors with counters for out-of-sequence frames (CntErrOutOfSequenceA and CntErrOutOfSequenceB) and mismatches on each adapter (CntErrWrongLanA and CntErrWrongLanB) Additionally, the table records the number of frames received (CntReceivedA and CntReceivedB), a cursor for limiting the drop window (StartSeqA and StartSeqB), and timestamps for the last received frame (TimeLastSeenA and TimeLastSeenB) Lastly, it includes boolean indicators (SanA and SanB) to denote if the remote node is likely a SAN or uses duplicate accept.
NOTE 1 The table contains for each remote node one row for the unicast frames and one row for each multicast or broadcast address that remote node is sending It contains one row for each unicast, multicast of broadcast address this node is sending
NOTE 2 Some fields are irrelevant for a SAN
NOTE 3 This is a conceptual view, distinct tables for destination and source nodes could be implemented
The Redundancy Control Trailer (RCT) in each DANP frame consists of four octets, structured as follows: a 16-bit sequence number (SequenceNr) is transmitted with the most significant 8 bits in the first octet, reflecting the SendSeq counter for the destination node Additionally, a 4-bit LAN identifier (Lan) is included as the most significant 4 bits of the third octet, with the sequence “1010” for LAN_A and “1011” for LAN_B Furthermore, a 12-bit LSDU size (LSDU_size) is represented by the most significant 4 bits in the least significant 4 bits of the third octet, indicating the size in octets of the LSDU from the end of the Protocol Type (PT) field, as defined in ISO/IEC 8802-3 and IEEE 802.1Q, including the RCT but excluding the PT and the frame part following the RCT.
NOTE Padding inserted before the RCT is included in the LSDU size, padding inserted after the RCT is not included in the LSDU size
The sender can restrict the LSDU size to ensure that the total frame, including the four-octet redundancy control trailer, remains within the maximum size permitted on the LAN while functioning in duplicate discard mode.
NOTE 1 This maximum size is currently 1 518 octets for VLAN untagged frames according to IEEE 802.3:2005 NOTE 2 This specification does not apply to the LRE, but to its upper layers
When sending a frame coming from its upper layers, a node shall: a) update the nodes table:
If the destination address—whether unicast, multicast, or broadcast—is not present in the nodes table, an entry should be created, recording the current time as TimeLastSeenA and TimeLastSeenB For unicast addresses, set SanA and SanB to 1; for multicast or broadcast addresses, set them to 0 All other values should be reset to 0, except for the SendSeq sequence number, which can be assigned an arbitrary value, ideally 1.
• if the destination address (single cast, multicast or broadcast address) is already in the nodes table, increment the sequence number SendSeq for that address, wrapping over through 0;
• if the destination address is a multicast address or the broadcast address, update in addition the TimeLastSeenA and TimeLastSeenB counters
NOTE 1 Updating TimeLastSeenA, respectively TimeLastSeenB at sending initializes the ageing time for the remote node The receiving process actualizes this time value when it receives a frame from that node A time-out process removes the entry
NOTE 2 Duplicate discard is assumed for multicast/broadcast addresses, since no PRP_Supervision frame tells the mode For unicast addresses, the remote node is likely a SAN on LAN_A or LAN_B If the destination is a DANP, an entry in the nodes table probably exists due to a previously received PRP_Supervision frame, or one is coming soon b) send
• if either SanA or SanB is set, send the frame unchanged over the corresponding adapter;
• if both are set, send the frame unchanged over both adapters;
If no settings are configured, the Redundancy Control Trailer (RCT) should be added between the LSDU (payload) and the Frame Check Sequence (FCS), ideally just before the FCS when padding is applied Subsequently, transmit the modified frame with LAN identifier “A” via adapter A and the frame with LAN identifier “B” through adapter B, following the same conditions outlined in section 4.2.6.1.
Upon receiving a frame that does not conform to the BPDU standards set by IEEE 802.1Q on either adapter, a node must take specific actions: if the adapter indicates that the frame contains an error, it should increase the error counter for the corresponding adapter, either CntErrorsA or CntErrorsB, and disregard the frame; otherwise, it will proceed with further processing.
If the frame is neither a PRP_Supervision frame nor a BPDU, and its source MAC address is not present in the nodes table, an entry should be created for that source MAC address, categorizing it as either a SANA or a SANB based on the LAN from which the frame originates.
• if the frame is received from LAN_B from a node registered as SANA, or over LAN_A from a node registered as SANB, set SanA = SanB = 1 for that source;
If the frame is identified as a PRP_Supervision frame and its source is not present in the nodes table, an entry should be created for that source, determining whether to accept or discard duplicates based on the contents of the PRP_Supervision frame Conversely, if the source already exists in the nodes table, its status must be updated to reflect either DANP duplicate accept or duplicate discard.
• record the local time at which the frame was received in the TimeLastSeenA, respectively TimeLastSeenB fields of the nodes table for that source;
• increment by one (wrapping through 0) the counters CntReceivedA, respectively CntReceivedB of the nodes table for that source and address kind
Updating SanA and SanB enables the transfer of a SAN between LAN_A and LAN_B During this process, the DANP will broadcast on both LANs, but after the NodeForgetTime, it will only transmit on the appropriate LAN.
4.2.7.4.2 Identification of frames associated with the duplicate discard mode
A receiver identifies a frame as a duplicate candidate if the last 12 bits before the Frame Check Sequence (FCS) match the physical size of the Logical Service Data Unit (LSDU) as illustrated in Figure 6 However, for smaller frames that utilize padding, the receiver must scan the frame backwards until it locates a matching size field, ceasing the search upon reaching the Length Type (LT) field.
NOTE 1 Small frames using padding are smaller than 64 octets
NOTE 2 Reception of a RCT is not a sufficient criterion to declare its source as DANP, since some protocols reply with the same frame as received
A receiver shall check for a frame identified as a duplicate candidate that the four bits previous to the size are either 1 010 (A) or 1 011 (B)
If the LAN identifier of a received frame does not match the adapter of the source device, the receiver will increment the CntErrWrongLanA and CntErrWrongLanB counters in the nodes table and forward the unchanged frame to the upper layers.
NOTE If one SAN is moved from LAN_A to LAN_B, it will first be considered DANP duplicate accept for the duration of NodeForgetTime before it becomes a SAN B
A receiver may employ any technique to eliminate duplicate frames, ensuring that it does not remove a single frame or both frames of a pair In cases of uncertainty, it is acceptable to forward both frames of a pair to the higher protocol layers.
The following drop window algorithm is recommended and uses the following fields: source MAC address, destination MAC address (or multicast address), RCT
PRP service specification
Arguments
The arguments are utilized in both commands and responses, as illustrated in Table 3 In a command (PRP write), they specify the intended configuration, while in a status (PRP read), they reflect the current configuration.
NodeName Node name in the LRE VisibleString32
ManufacturerName Name of the LRE manufacturer VisibleString255
VersionName Version of the LRE software VisibleString32
MacAddressA MAC address to be used by network interface A Unsigned48
MacAddressB MAC address to be used by network interface B Unsigned48
AdapterActiveA Adapter A is commanded to be active or responds that it is active if true
AdapterActiveB Adapter B is commanded to be active or responds that it is active if true
DuplicateDiscard Duplicate discard algorithm is (to be) used at reception and the RCT is (to be) appended at sending if true
TransparentReception RCT is not (to be) removed when forwarding to the upper layers if true Boolean1
The configuration of the LRE (Local Resource Element) varies based on the SwitchingEndNode value If the value is 0, the LRE is not configured as a switching node A value of 1 indicates that the LRE is set up as an SRP (Service Routing Protocol) switching node, while a value of 2 configures it as an RSTP (Rapid Spanning Tree Protocol) switching node If the value is 4, the LRE is configured as an MRP (Media Redundancy Protocol) switching node A value of 5 signifies that the LRE is configured as an HSR (High-availability Seamless Redundancy) switching node For values 6, 7, and 8, the LRE is configured as a RedBox in H mode, A mode, and B mode, respectively.
NodesTableClear Nodes table is (to be) cleared if true Boolean1
SupervisionAddress Address to be used for PRP_Supervision frames Unsigned 48
LifeCheckInterval Interval at which the PRP_Supervision frame is (to be) sent in milliseconds
NodeForgetTime Interval at which the nodes table entry of a node is (to be) cleared, in seconds Unsigned16
DropWindowMax Maximum size of the drop window to be used Unsigned16
CntTotalSentA Number of frames sent over adapter A Unsigned32
CntTotalSentB Number of frames sent over adapter B Unsigned32
CntTotalReceivedA Number of frames received over adapter A Unsigned32
CntTotalReceivedB Number of frames received over adapter B Unsigned32
CntErrorsA Number of transmission errors on adapter A, as signalled by the adapter
CntErrorsB Number of transmission errors on adapter B, as signalled by the adapter
CntNodes Number of nodes in NodesTable Unsigned16
NodesTable Records for all nodes that have been detected within the last NodeForgetTime the following fields
NodesTable
The node table (Table 4) keeps for network management purpose the record of all nodes that have been detected on the network
NOTE 1 The key attribute of the Nodes table is MacAddressA as received in the PRP_Supervision frame sent by a DANP
NOTE 2 Most of these attributes exist not only in one instance per physical remote node, but also as separate instances for each multi/broadcast address used by that node, and some also for each multi/broadcast address used by this (local) node (See 4.2.7.1)
MacAddressA MAC address of the source node (6 octets) OctetString6
MacAddressB a MAC address of the source node (6 octets) as seen over adapter B, as advertised by the PRP_Supervision frame
CntReceivedA Number of frames received from that source over LAN_A Unsigned32
CntReceivedB Number of frames received from that source over LAN_B Unsigned32
CntKeptFramesA Number of frames that were kept because they were out of the drop window on LAN_A
CntKeptFramesB Number of frames that were kept because they were out of the drop window on LAN_B Unsigned32
CntErrOutOfSequenceA Number of frames that were out of sequence on LAN_A Unsigned32
CntErrOutOfSequenceB Number of frames that were out of sequence on LAN_B Unsigned32
CntErrWrongLanA Number of frames that were received with the wrong LAN identifier on LAN_A
CntErrWrongLanB Number of frames that were received with the wrong LAN identifier on LAN_B
TimeLastSeenA UTC time at which the latest frame was received over
TimeLastSeenB UTC time at which the latest frame was received over
SanA True if the remote device is most probably a SAN accessible over adapter A
SanB True if the remote device is most probably a SAN accessible over adapter B Boolean1
SendSeq Sequence number used to communicate with that remote device
Unsigned16 a MacAddressB is not a key attribute.
PRP write
This service shall be used to write values to the LRE of a DANP to control the PRP Table 5 shows the parameters of this service
Parameter name Req Ind Rsp Cnf
Parameter name Req Ind Rsp Cnf
S(=) M(=) NOTE For the meaning of Req, Ind, Rsp, Cnf, M, U and S, refer to ISO/IEC 10164-1
The argument shall convey the service specific parameters of the service request as defined in 4.3.1
This parameter indicates that the service request succeeded
This parameter shall return 0 (no error condition detected)
This parameter indicates that the service request failed
This parameter specifies the error condition (see MIB in Clause 7)
PRP read
This service shall be used to read the current status of the LRE from a DANP Table 6 shows the parameters of this service
Parameter name Req Ind Rsp Cnf
Parameter name Req Ind Rsp Cnf
M(=) M(=) M(=) M(=) M(=) M(=) S(=) M(=) NOTE For the meaning of Req, Ind, Rsp, Cnf, M, U and S, refer to ISO/IEC 10164-1
The argument shall convey the service specific parameters of the service request as defined in 4.3.1
This parameter indicates that the service request succeeded
This parameter indicates that the service request failed
This parameter specifies the error condition (see MIB in Clause 7)
5 High-availability Seamless Redundancy (HSR)
HSR objectives
Clause 5 outlines how the PRP principles from Clause 4 are utilized to establish High-availability Seamless Redundancy (HSR), ensuring zero recovery time while being applicable to various topologies, especially in ring configurations and interconnected rings.
HSR significantly reduces network infrastructure requirements by approximately 50% compared to traditional PRP In contrast to rings based on IEEE 802.1D (RSTP), IEC 62439-2 (MRP), or IEC 62439-6 (DRP), the available bandwidth for network traffic is also halved Only HSR-capable switching end nodes can be part of the ring, as general-purpose nodes (SANs) must connect through a RedBox (redundancy box) for proper integration.
HSR principle of operation
Basic operation with a ring topology
As in PRP, a node has two ports operated in parallel; it is a DANH (Doubly Attached Node with HSR protocol)
A basic High-Speed Ring (HSR) network features doubly attached switching nodes, each equipped with two ring ports, connected through full-duplex links This configuration is illustrated in Figures 13 and 14, which depict multicast and unicast scenarios within a ring topology.
RedBox singly attached nodes interlink destinations
The key red, dotted arrows labeled "A" outline the green, cross-hatched arrows marked "B," while the blue arrows represent non-HSR frames exchanged between the ring and the host The cross frame is subsequently removed from the ring by the next node.
Figure 13 – HSR example of ring configuration for multicast traffic
A source DANH sends a frame passed from its upper layers (“C” frame), inserts an HSR tag to identify frame duplicates and sends a frame over each port (“A”-frame and “B”-frame)
In a fault-free state, destination DANH receives two identical frames from each port within a specified interval, processes the first frame by removing the HSR tag before forwarding it to the upper layers as a "D"-frame, and discards any duplicates.
The nodes support the IEEE 802.1D bridge functionality and forward frames from one port to the other, except if they already sent the same frame in that same direction
In particular, the node will not forward a frame that it injected into the ring
„A“-frame „B“-frame switch RedBox singly attached nodes interlink
The key red dotted arrows labeled "A" indicate the frames, while the green cross-hatched arrows labeled "B" represent the frames exchanged between the ring and host Additionally, the blue arrows signify non-HSR frames, which are removed from the ring by the subsequent node.
Figure 14 – HSR example of ring configuration for unicast traffic
A destination node of a unicast frame does not forward a frame for which it is the only destination
Frames in the ring are tagged with an HSR identifier by the source, which includes a sequence number This doublet of {source MAC address, sequence number} serves to uniquely identify different copies of the same frame.
The time skew between two frames in a network depends on the relative positions of the receiving and sending nodes In a worst-case scenario, where each node in a ring transmits its maximum frame size of 1,536 octets simultaneously, a delay of 125 microseconds can be introduced at a speed of 100 Mbit/s Consequently, with 50 nodes, the time skew may exceed 6 milliseconds.
DANH node structure
Figure 15 illustrates a conceptual hardware structure of a DANH, though practical implementations may vary The two HSR ports, A and B, along with device port C, are interconnected via the LRE, which features a switching matrix that facilitates frame forwarding between ports This switching matrix enables cut-through switching, while the LRE provides an interface to higher layers that is consistent with a standard Ethernet transceiver.
The input circuit verifies whether the node is the intended destination for the frame, while also performing VLAN and multicast filtering to reduce processor load Additionally, duplicate discard functionality is implemented within the output queues.
TX_A RX_A duplicate discard and untagger mux mux demux duplicate discard duplicate discard demux network layer transport layer publisher/ subscriber applications mux
RX_C TX_C forwarding filtering link redundancy entity (LRE) upper layers link layer interface
Figure 15 –HSR structure of a DANH
Topology
5.2.3.1 Attachment of singly attached nodes
Singly attached nodes (SAN), such as maintenance laptops or printers, cannot be directly connected to the ring due to their single port and inability to interpret HSR tags in frames Instead, SANs communicate with ring devices via a RedBox, which serves as a proxy for the attached SANs For more information on the RedBox, refer to section 5.2.4.
Connecting non-HSR nodes to ring ports, breaking the ring, is not covered by this document Non-HSR traffic within the ring is not permitted
5.2.3.2 Use of HSR with separate LANs
HSR nodes can be connected in the same way as PRP nodes In this case, the HSR nodes do not forward frames from port to port (HSR_PRP mode)
However, SANs cannot be attached directly to such a duplicated network unless they are able to interpret the HSR tag See Figure 16 below
IEC 370/10 switch switch switched local area network (tree) LAN_B switch switch switch switch
RedBox switched local area network (ring) LAN_A
Figure 16 – HSR example of topology using two independent networks
Quadruple port devices, known as QuadBoxes, can connect two High-Speed Rings (HSR), as illustrated in Figure 17 This setup is beneficial when traffic flow surpasses the capacity of a single ring However, it is important to note that end-to-end transmission delays remain unchanged.
Although one QuadBox is sufficient to conduct the traffic in the fault-free state of the network, two QuadBoxes are used to prevent a single point of failure
A Quadbox functions as an HSR node by forwarding frames across each ring and transmitting them unchanged to the other ring, unless the frame is identified as one that should not be forwarded To achieve this, a Quadbox filters traffic based on criteria such as multicast or VLAN filtering However, it does not learn MAC addresses, as this could cause communication disruptions if the Quadbox that learned the address fails while forwarding network traffic.
The interconnected rings of QuadBoxes operate within the same redundancy domain for fault tolerance If one QuadBox fails, both rings enter a degraded state, compromising their ability to withstand additional faults.
Constructing QuadBoxes similarly to RedBoxes ensures independent redundancy A QuadBox comprises two devices linked by an interlink, which is why RedBox specifications incorporate the HSR connection.
DANH DANH DANH DANH source destination interlink
Figure 17 – HSR example of peer coupling of two rings
The presence of two QuadBoxes on the same ring results in the transfer of two copies of the same frame from the first ring to the second, with each copy generating an additional two copies.
The second QuadBox on the second ring does not circulate four frames because it will not forward a copy from the first QuadBox if it has already sent a copy received from its interlink If the second QuadBox has not yet received a copy from its interlink, it will forward the frame, but it will not forward any subsequent copies from the interlink.
When a QuadBox receives a frame it injected into the ring or one inserted by another QuadBox, it forwards the frame to the interlink and its other port if it hasn't already sent a copy Although this may increase traffic on the interlink, it simplifies the design of the logic by ensuring that duplicates are discarded at the other end.
NOTE The maximum time skew between two frames of a pair is about the same as if all nodes were on the same ring
An HSR network may consist of rings connected by QuadBoxes, as Figure 18 shows
Figure 18 – HSR example of connected rings
Although a single QuadBox is sufficient to sustain the traffic, two independent QuadBoxes are needed to avoid a single point of failure
Some SANs are connected directly to the DANH that performs the duty of a simplified RedBox
5.2.3.5 Connection of an HSR ring to a PRP network
A High-Speed Ring (HSR) can be connected to a Parallel Redundancy Protocol (PRP) network using two RedBoxes, one for each Local Area Network (LAN) These RedBoxes are specifically configured to handle PRP traffic on the interlink while managing HSR traffic on the ring ports, as illustrated in Figure 19.
The sequence number from the PRP RCT is utilized for the HSR tag, enabling communication associations to remain intact during the transition between networks This approach also aids in identifying pairs and duplicates on the HSR ring, which can occur due to dual injections into the ring via the two HSR RedBoxes.
IEC 373/10 end node end node end node
RedBox A RedBox B interlink A interlink B destination end node end node
B A end node source end node
Figure 19 – HSR example of coupling two redundant PRP LANs to a ring
The HSR RedBoxes designed for linking the ring to a PRP network function similarly to the HSR RedBoxes utilized for connecting SANs, as outlined in section 5.2.3.1 However, these RedBoxes are specifically configured as RedBox “A” or RedBox “B” to accommodate PRP frames on their interlink.
In Figure 19, both RedBox A and RedBox B transmit identical frames (A and AB for A, and B and BA for B) However, if a RedBox receives a frame before it has the chance to send its own, it will hold back from sending.
In the scenario depicted in Figure 19, RedBox A will refrain from generating an "A" frame for LAN A if it has already received the same frame labeled "AB" from the ring Conversely, RedBox B will produce an "AB" frame only if it has not previously received an "A" frame from the ring, which occurs when frame "A" is not a multicast frame.
Multicast frames or unicast frames that lack a receiver in the ring are eliminated by the RedBox that initially inserted them, provided they originated from outside the ring.
Figure 20 shows the same coupling when the source is within the ring
IEC 374/10 end node end node end node
RedBox A RedBox B interlink A interlink B source end node end node
B A end node end node destination
Figure 20 – HSR example of coupling from a ring node to redundant PRP LANs
To configure the RedBox for optimal performance, it should be set up to connect to either SAN or PRP, as it is essential for the RedBox to insert the PRP trailer Operating the RedBox continuously in PRP mode is acceptable, as the PRP trailer remains undetectable by the SANs.
RedBox structure
Figure 22 shows the general structure of a RedBox
CCW proxy node table to singly attached nodes interlink link redundancy entity
(LRE) network layer transport layer layer 2 access RedBox local applications switch discard duplicate discard duplicate
HSR port A HSR port B port C ports D1 Dn
Figure 22 – HSR structure of a RedBox
The RedBox has a LRE that performs the duties of the HSR protocol
A RedBox can function in three distinct modes: SAN, PRP, or HSR connection The method of frame handling at the interlink interface varies based on the selected mode of operation.
The RedBox receives the frames to be sent from its own upper layers or from other nodes over its interlink
The RedBox identifies the source node and adds it to its proxy node table, creating a new entry with a sequence number of 0 if the node is not already present.
If the frame has an HSR tag, the Redbox does not modify it
If the frame has a PRP trailer, the RedBox reuses the PRP sequence number of the RCT for the HSR tag
If the frame has no PRP trailer, the RedBox uses the sequence number of its proxy node table and increments it
The RedBox transmits frames from one port to another, except when a frame has already been sent or is associated with a node listed in the proxy node table.
The RedBox receives frames addressed to its own upper protocols or to one of the devices that it represents
If the destination node has been registered as an HSR node, the RedBox forwards the frame unchanged
When the destination node is registered as PRP, the RedBox eliminates the HSR tag and replaces it with the PRP tag, while reusing the sequence number from the HSR tag for the RCT.
If the destination node is neither a PRP nor an HSR node, the RedBox removes the HSR tag
The switch in Figure 22 may be incorporated into the RedBox, so the interlink becomes an internal connection
Each node features a basic RedBox, as the LRE transitions to a single non-HSR host Additionally, it is common for nodes to contain multiple hosts, often including a maintenance port.
HSR node specifications
Host sequence number
An HSR node shall maintain a sequence number on behalf it its host for each MAC address the host uses The sequence number is initialized with 0
The LRE identifies the host's MAC address by monitoring incoming frames, and it can also be manually configured In the absence of the host MAC address, the LRE forwards all HSR traffic to the host, interpreting unicast frames as multicast.
DANH receiving from its link layer interface
For each frame to send on behalf of its link layer interface, a source node shall:
If this frame is HSR or the destination node has been registered as non-HSR
Do not modify the frame; else (non-HSR frame and destination node not registered as non-HSR)
Insert the HSR tag with the sequence number of the host;
Increment the sequence number, wrapping through 0
Duplicate the frame, enqueue it for sending into both HSR ports
NOTE 1 Enqueuing means that the frame will be sent as soon as no former or higher-priority frames are in the queue and the medium is ready
NOTE 2 Sending a non-HSR frame to both ports should not cause circulating frames since such frames will not be forwarded by the adjacent HSR node This mechanism is intended to allow off-ring configuration of an HSR node through a normal PC.
DANH receiving from an HSR port
A node receiving a frame from one of its HSR ports shall:
If this frame is not HSR-tagged:
Register the source in its node table as non-HSR node;
Enqueue the unchanged frame for passing to its link layer interface
(the frame is not forwarded)
Register the source in its node table as HSR node;
If this node is the (unicast or multicast) destination:
If this is the first occurrence of the frame over the link layer interface:
Register the occurrence of that frame;
Remove the HSR tag and pass the modified frame to its link layer interface
Else (this is not the first occurrence of the frame over the link layer interface):
Register the occurrence of that frame;
Do not pass the frame to the link layer interface
Else (if this node is not a destination):
Do not pass the frame to the link layer interface
If this node is not the only destination (multicast or unicast for another node):
If this is the first occurrence of the frame over the second port:
Register the occurrence of that frame;
Enqueue the unmodified frame for sending over the second port
Else (this is not the first occurrence of the frame over the second port):
Register the occurrence of that frame;
Else (If this node is the only (unicast) destination):
NOTE 1 It is possible that more than one duplicate arrives, especially when rings are coupled.
DANH forwarding rules
A node must avoid transmitting a frame that is a duplicate of one previously sent over the same port in the same direction This behavior is further detailed in section 5.3.3.
A node shall not send back a frame over the port which received it
A node that monitors signal quality will not forward a frame if it detects damage or truncation However, if a node using cut-through forwarding begins to transmit a frame and later identifies it as damaged or truncated, it will append the error sequence specified in ISO/IEC 8802-3:2000, section 27.3.1.4.2, before halting the transmission of that frame.
When a previously connected port is disconnected from the network, the node must clear the port's buffer to prevent the transmission of outdated frames Buffering will only be permitted once the port is reconnected.
If a node receives a supervision frame from a previously connected node indicating reinitialization, it shall purge the buffers from the entries corresponding to that node
NOTE 1 These rules remove circulating HSR frames and open the ring, in the same way as an RSTP or similar protocol It applies to frames originally sourced by the node and to frames circulating in case a device is removed after having sent a frame, and the ring is closed again, for instance by a mechanical bridging device or when a DANH is powered down In a ring of 50 nodes, there may be a delay of some 6 ms until a frame comes back to its originator, so this possibility must be cared for
NOTE 2 These conditions enable a node to operate either in store-and-forward or in cut-through mode Delaying the forwarding of a frame does not affect the worst-case ring delay
NOTE 3 The duplicate discard method of PRP is not a preferred method for discarding duplicates in HSR, since HSR aims at preventing duplicates from circulating
NOTE 4 The fact that the sequence numbers of the frames sent by one source are not monotonically increasing is not a reason for discarding the frame This observation can however be used for supervision of the network
NOTE 5 For cut-through operation, the node must wait approximately 5 (s at 100 Mbit/s until the HSR tag has been completely received and the node decided to forward or not By contrast, store-and-forward takes at least
122 (s at 100 Mbit/s for the maximum size frame (1 522 octets).
CoS
For the operation of HSR, priorities and VLANs are not required
An HSR node is expected, as expressed in its PICS:
• to support at least 2 levels of priority according to IEEE 802.1D (IEEE 802.1p);
• to filter VLAN traffic according to IEEE 802.1Q;
Clock synchronization
HSR does not specify the clock synchronization method that has to be used
When utilizing IEC 61588 (IEEE 1588), it is advisable to implement transparent ordinary clocks (hybrid clocks) in one-step mode This approach addresses the issue of clock synchronization frames arriving at both ports with varying delays, ensuring accurate P-delay measurements are conducted directly between adjacent nodes, as specified in IEC 61588 (IEEE 1588) v2.
NOTE One-step clocks require on-the-fly modification of the clock correction, which is only practical when done in hardware.
Deterministic medium access
HSR does not specify the traffic control that has to be used for deterministic, real-time operation
To optimize network performance, it is advisable to buffer high-priority, hard real-time frames and synchronize their transmission across all devices at a specific time This approach ensures that sufficient contiguous bandwidth is available for non-real-time traffic.