Re: XAUI and 64b/66b
Seto,
Please pay attention to the various PHY proposals.
There is a LAN only PHY that was originally 8B10B encoded. Then there was
the WAN compatable PHY that was frame stuffed scramble encoded. There was a
major war over the MAC transfer rate of the two options, that was resolved
by having the PHYs seperated LAN only and WAN compatable. Then there was
Hari, that was supposed to be optional, but for some reason was between the
PCS and PMA, that prevented the WAN compatable PHY from being able to
function within the definitions of a PHY. Then came 64B/66B encoding that
for some reason had 8B10B as a precoding, making "Hari" now a requirement
again. (A verbal conversation with one of the 64B/66B presentors yielded the
answer that 8B10B was required in order to do symbol error detection.) Then
came "XAUI" which is "Hari" under another name, but at least it was supposed
to be an optional physical XGMII extendor, but for some reason did not
duplicate the XGMII signals at both ends. One end of "XAUI" had the 8B10B
symbols instead. Then came the "UniPHY" which was supposed to provide a
common PHY that satisfied the requirements for both the LAN and WAN
compatable PHYs, based on the same 64B/66B encoding that required the 8B10B
precoding, that did not satisfiy the MAC transfer rates in the objectives of
either the LAN only PHY or the WAN compatible PHY. How am I doing? Do you
see why I am concerned about the true "optional" nature of "XAUI", in spite
of the label of "optional" that its proposers are using?
Thank you,
Roy Bynum
----- Original Message -----
From: Seto, Koichiro <seto@xxxxxxxxxxxxxxxxxxxx>
To: <rabynum@xxxxxxxxxxxxxx>; <rtaborek@xxxxxxxxxxx>;
<stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, March 23, 2000 8:32 AM
Subject: Re: XAUI and 64b/66b
>
> [Date: 03/23/2000 From Seto]
>
> Roy,
>
> I don't understand why you keep thinking 8B10B is a requirement when Rich
and
> others keep explaining this be optional. I don't see any statement that
8B10B
> is a requirement except from you. Please explain that part first so that
I
> can understand your concern better.
>
> BTW 10b interface is an optional interface to 802.3z Gigabit Ethernet
only.
> 10b interface is not either an option or requirement for 802.3ab Gigabit
> Ethernet. In this manner, XAUI interface can be non-option for WAN PHY if
WG
> agrees so.
>
> Seto
>
> >
> > Rich,
> >
> > My point was that I knew when not to become emotional about a
technology. I
> > realize that you, and the other people that are supporting 8B10B in such
a
> > way as to make it a requirement, have a vested interest in making sure
that
> > 8B10B stays a integral part of the standard. The effort to push 64B/66B
> > block coding for a "UniPHY" is just another attempt to make 8B10B a
> > requirement. I have no problem with it being a requirement of a LAN
only
> > PHY. I do have a problem with a small group of people, with vested
> > interests, attempting burden the WAN PHY, which they did not want in the
> > first place.
> >
> > Please don't make your vested interests a liability to the standard.
Please
> > allow XAUI to be optional in that the XGMII signals are at both ends of
XAUI
> > within the standard. If you and the other legacy LAN people want to
> > implement XAUI single ended, that is an implemenation issue, not a
standards
> > issue.
> >
> > I use the term "legacy" for 8B10B because it is left over from the
Gigabit
> > Ethernet standard. Frame deliniation and scamble coding are new to
this
> > group, just as 8B10B was before Gigabit Ethernet.
> >
> > Thank you,
> > Roy Bynum
> >
> > ----- Original Message -----
> > From: Rich Taborek <rtaborek@xxxxxxxxxxx>
> > To: HSSG <stds-802-3-hssg@xxxxxxxx>
> > Sent: Sunday, March 19, 2000 9:26 PM
> > Subject: Re: XAUI and 64b/66b
> >
> >
> > >
> > > Roy,
> > >
> > > Please go ahead and put together a proposal for the Serial PHY based
on
> > SDLC or
> > > HDLC. The complete proposal on the table for an 8B/10B-based XAUI/XGXS
is
> > backed
> > > by at least 24 companies. The complete proposal on the table for a
Serial
> > LAN
> > > PHY based on XAUI/XGXS and 64B/66B encoding is backed by at least 27
> > companies.
> > >
> > > I don't see any other complete XAUI/XGXS or Serial LAN PHY proposals
based
> > on
> > > SLP, HDLC, SDLC, SUPI or otherwise anywhere.
> > >
> > > I'd be very happy to compare proposals.
> > >
> > > P.S. XAUI is optional.
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > Roy Bynum wrote:
> > > >
> > > > Rich,
> > > >
> > > > What several people is saying that making the 8B10B codes a required
> > > > precursor to the 64B/66B encoding removes the "optional" label that
has
> > been
> > > > put on XAUI. You can have your cake and eat it too. Either XAUI is
an
> > > > optional XGMII extender and 8B10B is not part of the 64B/66B
encoding,
> > or
> > > > 8B10B is part of 64B/66B and XAUI is a requirement for all
> > implementations.
> > > >
> > > > While I laud your work and experience with 8B10B, there are other
> > solutions
> > > > that are just as elegant. I recognize that you have wanted 8B10B to
be
> > part
> > > > of the requirements for 10GbE from day one. This has perhaps
clouded
> > your
> > > > ability to be pragmatic.
> > > >
> > > > If I were not pragmatic about the uses of protocols, I would be
> > proposing
> > > > that we use HDLC, but I am not. SDLC and HDLC have been around
longer
> > than
> > > > 8B10B as communications protocols. I have been working with SDLC
and
> > HDLC
> > > > as long if not longer than you have with 8B10B. The first protocol
that
> > I
> > > > used to any extent other than SDLC was BiSync (1968). Do you see me
> > > > suggesting these? I am pragmatic and unlike the IETF, recognize
that
> > HDLC
> > > > has some major flaws and should not be part of the requirements for
> > 10GbE.
> > > >
> > > > Again, is XAUI going to be optional or not? If it is not optional,
then
> > I
> > > > think that you are going to have a hard time getting 75% of the
people
> > to
> > > > include it in the standard. If XAUI is optional, then 8B10B
encoding
> > can
> > > > not be a required precursor to any PCS. Which is it?
> > > >
> > > > With respects,
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > ----- Original Message -----
> > > > From: Rich Taborek <rtaborek@xxxxxxxxxxx>
> > > > To: HSSG <stds-802-3-hssg@xxxxxxxx>
> > > > Sent: Thursday, March 16, 2000 4:22 PM
> > > > Subject: Re: XAUI and 64b/66b
> > > >
> > > > >
> > > > > Ben,
> > > > >
> > > > > I disagree with your direction on this issue for the same reason
that
> > I
> > > > have
> > > > > trouble with the lack of specification of an optional interface in
> > > > 1000BASE-X
> > > > > which is implemented in 100% of Ethernet products implementing
> > 1000BASE-X.
> > > > I may
> > > > > be being politically incorrect in stating this, but I typically
like
> > > > products to
> > > > > match specs.
> > > > >
> > > > > I view XAUI as being a very prevalent 10 GbE interface, perhaps
not as
> > > > prevalent
> > > > > as the serial side of the GbE Ten-Bit-Interface. Barring no other
> > complete
> > > > and
> > > > > workable XAUI/XGXS proposals that meet the requirements of an
optional
> > > > XGMII
> > > > > extender, my view is that the PCS should accommodate the optional
> > XGMII
> > > > extender
> > > > > as well as operate properly without one. Since we'll have multiple
> > PCS's
> > > > > probably corresponding to PMA/PMDs, and one of the heavily backed
(27
> > > > companies)
> > > > > Serial PHY proposals endorse a 64B/66B PCS, I believe that this
PCS
> > should
> > > > > support the optional XGMII extender which is specified to be
PHY/PMD
> > > > > independent. The Serial PHY proposal already does this and I see
no
> > > > benefit or
> > > > > savings in cost, complexity, etc. in removing it.
> > > > >
> > > > > I also see no significant difference in complexity between
converting
> > > > between
> > > > > XGMII and PCS 64B/66B codes whether or not the IPG includes only
/I/
> > or
> > > > /A/K/R/.
> > > > >
> > > > > Best Regards,
> > > > > Rich
> > > > >
> > > > > --
> > > > >
> > > > > "Benjamin J. Brown" wrote:
> > > > > >
> > > > > > Rich,
> > > > > >
> > > > > > Jonathan just sent me a note saying that I was even confusing
> > > > > > him right now so I want to stop and ask my question again. I'll
> > > > > > try to make this as clear as possible.
> > > > > >
> > > > > > In the layer diagram that Brad showed in Albuquerque, the XAUI
> > > > > > was shown as an XGMII extender. To me this means that the
> > > > > > reconcilation sub-layer speaks using XGMII language and the PCS
> > > > > > listens using XGMII language. The XAUI can extend this interface
> > > > > > by translating from XGMII to XAUI but it must translate back
> > > > > > again before it gets to the PCS. The XGXS block is the
translator.
> > > > > >
> > > > > > The 64b/66b proposal as written ignores the XGXS block between
> > > > > > XAUI and the PCS. It is my contention that, though this would
> > > > > > work, it is unnecessary and even burdensome to those
implementors
> > > > > > that choose to not use XAUI. 64b/66b would work equally as well
> > > > > > without the XAUI specific control codes as they add nothing to
> > > > > > the efficiencies of 64b/66b (that I can tell). The XGMII
specific
> > > > > > control codes are completely adequate for 64b/66b. In my
opinion,
> > > > > > a serial PCS should be specified as if XAUI didn't exist.
> > > > > >
> > > > > > I'll even go so far as to state that, in my opinion, even a
> > > > > > parallel/CWDM PCS should be specified as if XAUI didn't exist.
> > > > > > If this PCS turns out to be identical to the XGXS block then
some
> > > > > > implementors may choose to avoid the encode/decode/encode as
> > > > > > specified in the standard, but I believe that is how it should
> > > > > > be specified.
> > > > > >
> > > > > > Is the question/comment still confusing or do you merely
disagree?
> > > > > >
> > > > > > Ben
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> > >
> >
> >
>