Re: XAUI and 64b/66b
[Date: 03/24/2000 From Seto]
Roy,
Many things you are putting on your concern list are irrelevant to the current
discussion. XAUI is not between PCS and PMA as far as I could see in the
latest proposals from last March meeting.
Seto
> 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@sj.hitachi-cable.com>
> To: <rabynum@mindspring.com>; <rtaborek@nserial.com>;
> <stds-802-3-hssg@ieee.org>
> 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@nserial.com>
> > > To: HSSG <stds-802-3-hssg@ieee.org>
> > > 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@nSerial.com>
> > > > > To: HSSG <stds-802-3-hssg@ieee.org>
> > > > > 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@nSerial.com
> > > > Santa Clara, CA 95054 http://www.nSerial.com
> > > >
> > > >
> > >
> > >
> >
>