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

Re: [10GBT] Frame delineation in 10GBT



Hugh,

Good point.  Ethernet in the past has had a lot of success because it
hasn't re-invented the wheel for every part of the solution.  Re-use of
auto-negotiation, 64B/66B, 64/65 octet encapsulation, etc. are worth
considering.  As a note though, not everyone may have access to the
802.3ah clause, so if you have a high-level overview of this information
or can point to a presentation on the EFM web site, it would be greatly
appreciated.

Thanks,
Brad

-----Original Message-----
From: stds-802-3-10gbt@IEEE.ORG [mailto:stds-802-3-10gbt@IEEE.ORG] On
Behalf Of Hugh Barrass
Sent: Friday, August 13, 2004 10:19 AM
To: STDS-802-3-10GBT@listserv.ieee.org
Subject: [10GBT] Frame delineation in 10GBT


Brad et al,

During the discussion on the proposal for framing in 10GBT, I mentioned
that I thought the 64/65 octet encapsulation used in .3ah (Clause 61.3)
would be a better proposition than 64b/66b (from .3ae) or 64b/65b (as
described in the presentation). I know that this is a relatively small
issue compared to the PAM-8 / PAM-12 discussion but I think that those
involved in PCS definition would benefit from a good reading of the .3ah
clause.

The main benefit of the 64/65 octet encapsulation is that it is byte
oriented and therefore much more straightforward to fit on top of the
byte oriented LDPC coding. It has a very low overhead (1/64, duh!) and
does not have any alignment issue with odd size frames. It also supports
IPG compression (although that is not relevant for 10G) and has some
spare codepoints for adding in prequalizer feedback data if required.

It might also be worth considering the use of 64/65 to cover the dual
function of LDPC block delineation as well as Ethernet frame
delineation. This would require the use of some more codepoints for
block flags, but shouldn't be difficult to achieve. I believe that we
could get a PCS encapsulation that is significantly simpler to define
and implement as well as being more robust and less overhead.

If anybody is interested in this, I'd be willing to go through it in
more detail - or else let me know that I am wasting my breath & I'll
drop the subject.

Hugh.