HSR operates entirely at Layer 2. It doesn’t add a new protocol on top of Ethernet — it inserts a six-byte tag into every frame before it enters the ring. That tag is how nodes identify duplicates, track which path a frame took, and know when to remove a frame from the ring. Understanding the tag structure is the foundation for understanding everything else about how HSR works.
Table of Contents
From C-Frame to A-Frame and B-Frame
A frame arriving at the LRE from the host is called a C-frame — a standard, untagged Ethernet frame. The LRE prefixes it with the HSR tag and sends two copies into the ring simultaneously: the A-frame goes out port A, the B-frame goes out port B. Both carry the same sequence number.
At the destination, the first copy to arrive is stripped of its HSR tag and passed up to the host as a D-frame — again, a standard Ethernet frame. The second copy is discarded by the duplicate discard mechanism. If the ring has a fault and only one copy arrives, the host never knows — it just gets the D-frame as normal.
The HSR tag is ring-private traffic. It is inserted at the source and removed at the destination. Intermediate nodes forward the tagged frame without touching the payload. The tag never reaches the host application.
The HSR Tag — Six Bytes
The HSR tag is inserted immediately after the source MAC address field, in the same position a VLAN tag would occupy. It is six bytes long and contains four fields:
HSR EtherType (2 bytes) — 0x892F
This is the registered EtherType for HSR. Its presence in the frame is what identifies it as an HSR-tagged frame. Nodes that don’t understand 0x892F will treat the frame as unknown and either drop it or forward it — which is why non-HSR devices cannot be placed directly on the ring.
Path field (4 bits) — PathId
The path field is split into two parts: the 3 most significant bits are the NetId, and the least significant bit is the LanId.
The NetId identifies where the frame originated. A value of 0 means the frame originated within the HSR ring. Values 1–6 identify frames originating from one of up to 6 PRP networks connected to the ring via RedBox pairs. Value 7 is reserved.
The LanId indicates which port of the RedBox injected the frame. For frames from PRP networks, LanId=0 means LAN A, LanId=1 means LAN B. For frames originating within the HSR ring, the LanId may indicate the sending port (A=0, B=1).
The full 4-bit PathId allocation is: 0000–0001 for frames from an HSR node (A or B port), 0010–1101 for frames from one of the 6 PRP networks (A or B), 1110–1111 reserved.
The PathId field is what prevents frames from a PRP network being reinjected back into the wrong PRP network when they circulate the ring. Without it, RedBox B could forward a frame back into LAN A, creating a loop.
LSDU size field (12 bits)
This field carries the size of the Link Service Data Unit — the payload including possible padding, but not the FCS. It has the same definition as in PRP.
The LSDU size serves a practical purpose: it allows a receiving node to quickly determine the end of the payload without having to parse the entire frame. It also ensures that after the HSR tag (and any VLAN tag) is removed, the resulting D-frame meets the minimum Ethernet frame size of 64 bytes. The minimum HSR frame size is 70 octets without VLAN and 74 octets with VLAN.
Sequence number (16 bits) — SeqNr
This is the duplicate detection field. The source node inserts the same sequence number in both the A-frame and B-frame of a pair. Each node maintains a counter per source MAC address and increments it by one for each frame it sends.
A receiving node tracks the {source MAC, sequence number} pair. When a frame arrives, the node checks if it has seen this combination before. If yes, it’s a duplicate and is discarded. If no, it’s passed to the upper layer.
The sequence number wraps around at 65535. The standard does not specify the duplicate detection algorithm — hash tables, queues, and sequence number tracking are all valid approaches. What the standard does require: a node shall never reject a frame it has not seen before, and shall detect nearly all duplicates. Occasional missed duplicates do not disturb operation, but missed new frames do.
Frame Position with VLAN Tag
If the frame carries a VLAN tag per IEEE 802.1Q, the HSR tag is inserted after the VLAN tag, not before it. This is intentional — it keeps the VLAN tag in its standard position immediately after the source MAC address, which allows faster MAC address lookup when Independent VLAN Learning is used.
Without a VLAN tag:
Frame Size Implications
The HSR tag adds 6 bytes to every frame on the ring. A standard maximum-size Ethernet frame of 1518 bytes becomes 1524 bytes with a VLAN tag and HSR tag combined, or 1520 bytes with only the HSR tag. These exceed the standard 1522-byte maximum for tagged Ethernet frames.
This is not a problem in practice because the HSR tag is ring-private traffic. It only exists between nodes on the ring — it never reaches an external Ethernet controller. The Ethernet controllers on each DANH only see C-frames and D-frames, which are standard size. The oversize frames are handled internally by the LRE hardware.
Supervision Frames
Supervision frames are a special category of HSR frames. Every DANH multicasts a supervision frame over both ports periodically to announce its presence on the ring and allow other nodes to verify ring continuity.
The supervision frame destination is a reserved multicast address (01-15-4E-00-01-XX). The HSR tag is present as normal, but the payload carries specific TLV-structured content:
- SupEthertype and SupPath — identifies this as a supervision frame and its direction
- SupSequenceNumber — an independent counter for supervision frames, separate from the data frame sequence counter
- TLV1 (type 23, length 6) — the MAC address of the DANH
- TLV2 (type 30, length 6) — the MAC address of the RedBox, if the DANH is being proxied by one
- TLV0 (type 0, length 0) — end of TLV list
The supervision frame is padded to 70 octets (no VLAN) or 74 octets (with VLAN). These sizes ensure that after the HSR tag is removed, the frame meets the 64-byte Ethernet minimum.
Supervision frames are sent periodically — the period is relatively long, on the order of seconds — because they are not needed for failover. HSR fails over in zero time regardless of supervision frame timing. Supervision frames exist only to detect lurking faults: degraded redundancy where one path has failed but traffic is still flowing on the other. A node that stops receiving supervision frames from one direction knows a path has failed even if data is still flowing normally.
Mode X does not apply to supervision frames. Both copies always circulate the full ring.
Duplicate Detection in Practice
The sequence number is 16 bits, giving a range of 0–65535. At high traffic rates a node could theoretically exhaust this range and wrap around. At 100 Mbit/s with minimum-size frames, a node could send roughly 148,000 frames per second — meaning the sequence number wraps in under half a second. Nodes must account for wrap-around in their duplicate detection logic.
The standard leaves the detection algorithm to the implementer, but notes that hash tables, queues, and sequence number tracking are all viable. What matters is the requirement: never reject a frame not previously seen, and detect nearly all duplicates. A missed duplicate results in a duplicate frame reaching the application — usually harmless. A missed new frame is a packet loss event.
Conclusion
The HSR tag is small — six bytes — but every critical mechanism in the protocol runs through it. The EtherType marks the frame as ring traffic. The sequence number drives duplicate detection. The PathId prevents loops at PRP-HSR boundaries. The LSDU size enables efficient processing. Get any of these wrong in an implementation and the ring either drops frames, lets duplicates through, or creates loops.
For commissioning and troubleshooting, knowing the tag structure means you can read a packet capture on the ring and immediately understand what you’re looking at — which direction the frame came from, whether it originated in the ring or from a PRP network, and whether the sequence numbers are incrementing correctly. That’s the practical value of understanding it at this level.