[RPRWG] fairness frame format
The fairness frame format in P802.17 is different
from user data and control frames. That in itself
is probably OK, except that it brings with it the
following deficiencies:
- 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?
- The above is more of a problem for MC_FCMs where the
messages are broadcast and are therefore processed
in the transit path at each hop. Of course, MC_FCMs are
only processed by the client (and not the MAC), so one
may argue that these messages are not that critical
to the operation of the MAC.
- These frames don't have a destination address. For
SC_FFs, this is probably OK since they travel
hop-by-hop. But MC_FFs go all the way around the
ring. If it's OK for MC_FFs not to have a DA,
why do all the other control messages need one?
This represents inconsistencies in the MAC
architecture.
I'd also appreciate pointers to any work showing the
usefulness of MC_FFs. To me the benefit of MC_FFs
is not at all clear and I'm not even convinced that
they achieve anything useful.
-Anoop
--
Anoop Ghanwani - Lantern Communications - 408-521-6707