Re: Interface reality check
Great work! I applaud your efforts.
Rick Walker wrote:
> 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
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com