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

[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