IEEE 802.1CB FRER: Missing or simplified features compared to standard

[mustafatopsakal]

While working with FRER (Frame Replication and Elimination for Reliability) simulations in INET Framework, I compared the current FRER-related modules against the IEEE 802.1CB specification. INET provides the core FRER functionality (stream identification, replication, elimination, and R-Tag encoding/decoding). However, several mechanisms explicitly defined in IEEE 802.1CB appear to be simplified or not implemented in the current INET implementation. The purpose of this issue is to clarify the intended scope and design decisions regarding these standard-defined mechanisms.

Differences

Feature (clarified)	IEEE 802.1CB Standard	INET Implementation	Status
Sequence number representation	16-bit unsigned, wrap-around defined	16-bit in R-Tag, internal int	Partial
Sequence number wrap-around handling	Mandatory, modulo-aware comparison	Not implemented	Missing
Sequence recovery history (data structure)	Vector Recovery Algorithm (bit-vector, configurable length)	Fixed-size list (bufferSize)	Simplified
Sequence recovery logic (decision algorithm)	Individual Recovery and Sequence Recovery	Duplicate presence check only	Missing
Sequence recovery reset mechanism	frerSeqRcvyResetMSec parameter	Not implemented	Missing
Latent Error Detection mechanism	Defined in IEEE 802.1CB	Not implemented	Missing
Take-No-Sequence operating mode	Defined in IEEE 802.1CB	Not supported	Missing

Observations:

• Duplicate elimination relies on a fixed-size sequence history list, instead of the Vector Recovery Algorithm defined in IEEE 802.1CB, which uses a bitmap-based sequence recovery history rather than storing sequence numbers as a list.
• Sequence number comparisons do not account for wrap-around, even though this behavior is explicitly required by the standard.
• Although the R-Tag carries a 16-bit sequence number, internal handling uses a wider integer type, which makes wrap-around behavior unclear.
• The absence of a sequence recovery reset mechanism may lead to incorrect duplicate classification after long idle periods.
• The Latent Error Detection mechanism defined in IEEE 802.1CB does not appear to be present in the current INET implementation.

Questions

1. Are these deviations from IEEE 802.1CB intentional design choices (for example, simplicity, performance, or scope considerations)?
2. Is full IEEE 802.1CB sequence recovery behavior considered out of scope for INET?
3. Are any of these standard-defined mechanisms planned or under consideration for future INET releases?

Any clarification on how these aspects are viewed within the INET project would be appreciated.

[levy]

1. no, these are not intentional differences or limitations, they are simply not implemented or ignored details
2. no, a full recovery implementation would be absolutely welcomed in INET
3. no, unfortunately we're not actively working on this part

I'm not sure how the vector algorithm operates exactly, but please note that storing a vector bits or a list of sequence numbers is pretty much equivalent from the simulation's perspective.

If you would like to add any or all of these features then we would be happy to review the changes. Please make them in smaller batches and submit individual PRs.