High availability seamless redundancy (HSR) is a further development of the PRP approach, although HSR functions primarily as a protocol for creating media redundancy while PRP, as described in the previous section, creates network redundancy. PRP and HSR are both described in the IEC 62439 3 standard. Unlike PRP, HSR is primarily designed for use in (redundantly coupled) ring topologies. Like PRP, it uses two network ports, but unlike PRP a HSR connection incorporates a DAN H (double attached node for HSR) that connects the two interfaces to form a ring (see Figure - HSR ring network). A frame from the application is given an HSR tag by the HSR connection.
Like the PRP RCT, this contains the length of the user data, the port that transmitted it and the sequence number of the frame.
However, unlike PRP, the HSR header is used to encapsulate the Ethernet frame. This has the advantage that duplicates of all frames are recognized in all devices as soon as the HSR header has been received. There is no need to wait for the whole frame and its RCT to be received before a duplicate can be recognized as such. This means that, similarly to cutthrough switching, individual HSR connections and RedBoxes can begin forwarding the frame to the second ringport as soon as its HSR header has been completely received and duplicate recognition carried out. Each HSR node takes from the network all frames that are addressed only to it and forwards them to the application. Multicast and broadcast messages are forwarded by every node in the ring and are also passed to the application. In order to prevent multicast and broadcast frames from circulating for ever, the node that initially placed the multicast or broadcast frame on the ring will remove it as soon as it has completed one cycle (see HSR data flow in Figure - HSR ring network).
HSR ring network Enlarge Picture
In contrast to PRP, it is not possible to integrate SAN nodes directly into an HSR network without breaking the ring: a SAN lacks the second network interface necessary for a closed ring. This is one reason why SANs can be connected to HSR networks only via redundancy boxes. The second reason is the encapsulation of the network traffic on the ring effected by the HSR header. Unlike with PRP, this prevents ordinary network nodes from participating in the HSR traffic. While SAN nodes interpret the PRP RCTs as padding, this is not possible for the HSR tag: its position in the frame means that it is always interpreted as valid layer 2 frame information, and this prevents SAN nodes from correctly reading out the frame’s user data.
Because some HSR devices may need to communicate with a management station or notebook for purposes of configuration and diagnostics, HSR connections will temporarily accept devices that transmit standard Ethernet frames, even on ringports. In this case the HSR connections communicate without HSR header encapsulation, although this traffic is not passed to the HSR network – it merely provides bidirectional communications between the configuring management station on an HSR port and the HSR device. Normal HSR communications is not restarted until the ring has been closed. Couplings between two HSR rings are always implemented by means of two ring coupling elements, known as QuadBoxes. These facilitate a coupling between two HSR with no single point of failure (see Figure - Coupled HSR rings (extract from IEC 62439 3)).
As regards switchover times, HSR behaves just like PRP: by sending duplicate frames from both the ports of an HSR connection, in the event of a failure one frame will still be transmitted via whichever network path is still intact.
This means that the redundancy again functions with zero switchover time and, unlike PRP, does not require two parallel networks. An HSR network, however, always has the form of a ring, or a structure of coupled rings, which means that it is less flexible than PRP at the installation stage.
The duplicate transmission of frames in both directions also means that effectively only 50% of the network bandwidth is available for data traffic.