Re: [10GBT] Frame delineation in 10GBT
Brad
all the Cu baseline proposals from EFM may be found at
http://www.ieee802.org/3/efm/baseline/copperbaseline.html
The encapsulation preso for C61 that Hugh was refering to is about half
way down the page, the last in the C61 presentations.
hope this helps
wael
Booth, Bradley wrote:
>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.
>
>
--
Wael William Diab
Editor-In-Chief, IEEE 802.3ah