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

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