RE: [RPRWG] fairness frame format
Additionally, we could swap the values of FT_FAIRNESS and FT_DATA such that it takes 2 bit changes to change between fairness and idle frames (and also 2 bit changes to change between data and control frames, but this is much less important).
-----Original Message-----
From: Leon Bruckman [mailto:leonb@xxxxxxxxxxxxx]
Sent: Sunday, April 27, 2003 1:16 AM
To: 'Anoop Ghanwani'; 'stds-802-17@xxxxxxxx'
Subject: 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