Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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