[RPRWG] Uniform fairness frame format (in response to Anoop)
Anoop,
I have similar concerns, but a slightly different resolution proposal.
>> - There is only a single bit parity check for TTL and
>> baseControl fields.
Other than "current implementations don't, there would be no reason
to not simply have the fairness FCS cover the whole frame. And, if
the header coverage were to be improved, by using a 32-bit FCS
(as proposed), then this would be a uniform/consistent way of
providing header-error coverage (with the small exception of
having two distinct (16 and 24-byte) header sizes.
>>But MC_FFs go all the way around the ring.
We might be better off calling this daCompact, than saCompact.
Its really one address that represents them both when they are
equal, so I don't see a significant functional problem here,
for single-choke or multi-choke fairness.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@xxxxxxxxxxxx
>> -----Original Message-----
>> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Anoop Ghanwani
>> Sent: Thursday, April 24, 2003 1:47 PM
>> To: 'stds-802-17@xxxxxxxx'
>> Subject: [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
>>