RE: [RPRWG] fairness frame format
Anoop,
- There is only a single bit parity check for TTL and
baseControl fields. This is insufficient. A couple
of bit flips in the right places, and a fairness
frame could get interpreted as something else.
Why can't we just stick with the basic frame
header that has a 16-bit HEC?
What is that "something else". The FCM is 16 bytes long, so if mistakenly
taken as a data or control packet it will be discarded because of HEC error,
FCS error, frame length, and maybe because of all these reason together.
If it is mistakenly interpreted as a Idle message, then it will be
discarded, and the fairness process will have to wait for the next FCM, no
big problem there.
The only possible issue is if a Idle frame (for whoever is using these
frames) is mistakenly interpreted as a FCM. In this case the fairness
process may take a "hit" since it may remove any active congestion points. I
have the feeling that this is not a major issue since the fairness will
eventually recover, but it may be a nice point to simulate.
Leon