Re: Interface reality check
Dear Mike,
> Mike Jenkins <jenkins@xxxxxxxx> writes:
> I applaud your rigorous standards expressed below (especially liked
> the analogy about cleaning up campsites), but I want to draw one
> distinction regarding control codes. The ordered set control code(s)
> (/O/) is (are) needed to transmit Fibre Channel traffic, not solely to
> enable XAUI. The needs of byte vs. word striping may vary, but that's
> another issue. Ordered sets (K28.5, Dxx.x, Dxx.x, Dxx.x) are a
> necessary part of Fibre Channel, as much as SOP, EOP, etc., are for
> Ethernet. (Since it's just K28.5, I admit I'm not sure whether it's
> extra control codes or just more frame types that are needed.)
I agree with you completely.
I fully support any mechanisms that are rationally agreed upon after
the standardization process.
> I realize that encompassing FC was not part of your original objective
> but use of 64b/66b code is being discussed here in the FC plenary
> sessions. I think we need to know soon if this code will or won't
> accommodate Fibre Channel.
Some people have questioned the idea of not allowing "code leakage".
Supporting /O/ characters is quite reasonable and completely independent
of the "code leakage" issue.
The 64b/66b codec will almost certainly be a superset of whatever 10 GbE
actually standardizes. This is similar to the existing case with
8b/10b and 1GbE. I certainly didn't want to imply that I am against
supporting a rich set of control codes. My point is really about the
process of standardizing code usage - not about crippling the code by
removing functionality.
That aside, I am working very hard to extend 64b/66b to support FC. Using
Information from Osamu Ishida and Rich Taborek, we believe that we should
support four distinct kinds of /O/ characters. Quoting from Osamu:
A) Interoperable XGENIE ordered sets,
B) Fibre Channel ordered sets,
C) Carrier Specific ordered sets (used in customized option chip),
D) Vendor Specific ordered sets.
I have developed a proposal to support all four kinds of ordered
sets for all the following frame types:
1) ZZZZ/ODDD
2) ODDD/ZZZZ
3) ODDD/ODDD
4) ODDD/SDDD
The penalty for doing this was that the hamming distance for control
symbols fell from 4 to 3. However, the TYPE bytes which determine
Ethernet packet boundaries are still 4-bit strong.
I believe this expanded code space will amply support Fiber Channel and any
possible extensions that we may or may not decide to standardize within
10 GbE.
I am not too worried about the reduction in control space hamming distance,
as the 3 bit distance is already better than the 8b/10b control space
hamming distance.
Best regards,
--
Rick Walker