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

Re: [10GBT] Frame delineation in 10GBT


After scanning clause 61, it appears to me that 64/65 octet encapsulation as it is now is missing some capability needed in 10GE. Can you clarify?

- Can it handle ordered sets (like LF/RF)?
- Can it transmit error control characters /E/ in the midst of a frame?

Additionally, I think it would need to be changed to enforce the Lane0 rule for /S/ symbols.

What advantage does this offer versus using 64b/65b grouped in blocks of eight such that they are byte aligned?

Best Regards,

-----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
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

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.