Re: XAUI and 64b/66b
Walter,
As a non-vendor participant, representing an industry that will buying a
large amount of these interfaces, I would like to reiterate your comments.
XAUI is being presented as an optional PHYSICAL DISTANCE EXTENDER for the
XGMII not an optional additional sublayer between the RS and the PCS. This
means that XAUI is inside the XGMII.
As an optional physical distance extender XAUI will give vendors more
flexibility to build larger form factor chassis. Why they would do that in
an era when customer would like to see the form factor reduced is a mystery
to me, but it is an option. As long as it remains optional, it also means
that vendors do not have to use XAUI when their chassis/ASIC form factor
does not require it. As a customer this gives me more options from diverse
vendors that remain interoperable. It has the effect of increasing the
overall market for more vendors and more customers.
I have attached a slide that represents what I understand the XAUI was
presented to be. Perhaps this will help explain my understanding and
provide a better center for the discussion.
Thank you,
Roy Bynum
----- Original Message -----
From: Walter Thirion <wthirion@xxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Friday, March 17, 2000 7:01 PM
Subject: RE: XAUI and 64b/66b
>
> Rich,
>
> Without reiterating all of the points Ben made, I think the following
> paragraph from Ben really summarizes it:
> ______________________________________________________________
> The picture does tend to get confusing. However, if the XAUI
> is an extension of the XGMII, and the XGMII isn't "there" how
> can a XAUI be "there"? This does seem silly. However,
> architecturally, I think these layers are required to avoid
> a certain amount of confusion.
> ______________________________________________________________
>
> We have been using the XGMII as the architectural interface between the RS
> and the PCS. Granted it is optional and, therefore, implementors are free
to
> use some other i/f. However, in the standard, we can't just assume magic
> happens between the layers, so the XGMII has been put in that role. If
XAUI
> had been presented (and accepted) first, then maybe we would be having a
> different discussion.
>
> So I recommend we leave XGMII as the specified i/f and allow XAUI to
> transparently extend it. Transparently means you can't tell whether XAUI
is
> present or not and, therefore, the PCS gets XGMII signals when XAUI is
> present just as it would when XAUI is not present.
>
> Walt
>
>
> > -----Original Message-----
> > From: Brown, Ben [BAY:NHBED:DS48] [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
> > Sent: Friday, March 17, 2000 10:21 AM
> > To: rtaborek@xxxxxxxxxxx
> > Cc: HSSG
> > Subject: Re: XAUI and 64b/66b
> >
> >
> >
> >
> > Rich,
> >
> > It sounds like we intend to agree to disagree (or at least I do).
> >
> > Rich Taborek wrote:
> > >
> > > Walt, et. al.
> > >
> > > Jonathan and I just spent well over an hour on the phone
> > discussing various
> > > points of view on this issue. I'm sensing that one can view
> > this issue form
> > > verious perspectives including architectural purity, actual
> > implementations,
> > > standards documentation to ensure interoperability but not restrict
> > > implementations, etc.
> > >
> > > First of all, let me try to succinctly state the issue: Ben
> > is asking why
> > > 64B/66B coding needs to map XGXS codes instead of simply
> > mapping RS codes.
> > >
> > > I don't believe that it helps at all for any architectural
> > descriptions or
> > > standards documentation to describe the interface on the
> > PCS side of the the
> > > XGXS as the XGMII. I say this because I believe that we're
> > getting completely
> > > caught up in interfaces to interfaces. Both architecturally
> > and with respect to
> > > an implementation, the proposed Reconciliation Sublayer,
> > not the XGMII,
> > > generates the control codes associated with the MAC data
> > which is to be passed
> > > to the PCS. The proposed XGMII is 36 bits wide plus one
> > clock signal in each
> > > direction. If the optional XGMII extender is employed,
> > 8B/10B encoding converts
> > > RS codes to XGXS codes. These codes are transported across
> > XAUI to the remote
> > > XGXS. The XGMII itself is optional.
> >
> > Just as you state, the XGMII is optional. Therefore any extension of
> > the XGMII is, too. To go further, any control codes supported by that
> > optional extension are optional. That leaves us only with the control
> > codes of the RS. I understand and support that implementations may
> > choose to perform this extension and control code mapping. I just
> > don't agree with forcing this control code mapping by specifying to
> > it in the standard. Here again, we simply disagree.
> >
> > >
> > > At this point it is important to note that:
> > >
> > > 1) There is no architectural or implementation value in
> > reverse-translating the
> > > XGXS code to that of the RS for any PCS including Serial,
> > WWDM, Parallel Optics
> > > or MultiLevel;
> >
> > It sounds like your opinion is that for implementations
> > which use XAUI, it is a pain to translate back to RS
> > control codes. I might agree with that. However, for
> > implementations that don't use XAUI, it is more of a
> > pain to make that translation. Another disagreement?
> >
> > >
> > > 2) For the sake of architectural purity, there is reason to
> > place an XGMI
> > > Interface between the XGXS and PCS. For implementation
> > sake, XAUI extends the
> > > XGMII by attaching to the end of the XGMII not in the middle of it.
> >
> > Definitely a disagreement (attaching to the end and not sitting
> > in the middle, I mean).
> >
> > >
> > > 3) The XGMII is optional, the RS is not. If an
> > implementation chooses to
> > > implement XAUI and not the XGMII, should the architecture
> > and standard dictate
> > > that XGXS codes be reverse-translated to RS codes? If so,
> > should there be a
> > > second Reconciliation sublayer between the XGXS and RS? See
> > how silly this gets?
> >
> > The picture does tend to get confusing. However, if the XAUI
> > is an extension of the XGMII, and the XGMII isn't "there" how
> > can a XAUI be "there"? This does seem silly. However,
> > architecturally, I think these layers are required to avoid
> > a certain amount of confusion.
> >
> > A PCS needs to use the same control codes as the RS. If there
> > is an XGMII between them, cool. If a XAUI extends that XGMII,
> > even cooler. For parallel/CWDM if the PCS is identical to the
> > RS side XGXS, then implementations would certainly be unlikely
> > to go back and forth with control codes. However, the picture
> > should be clear, silly or not. Another definite disagreement.
> >
> > >
> > > 4) If indeed you still believe that the Serial PCS should
> > reverse-translated
> > > XGXS codes (/A/K/R/'s) into RS codes (/I/'s) and the stream
> > gets all the way to
> > > the optional Remote XGXS adjacent to the Remote PCS, this
> > XGXS must regenerate
> > > the XGXS codes to support XAUI. It's much simpler to not do
> > thia translation
> > > twice.
> >
> > I would argue that implementations which do not use XAUI
> > won't have to do it at all. Another disagreement.
> >
> > >
> > > At this point, I'd like to ask some questions?
> > >
> > > What's the big deal about having the Serial PCS, and
> > specifically 64B/66B
> > > transport (/A/K/R/) instead of (/I/)?
> > >
> > > What is the achitecture, documentation or implementation or
> > other useful reason
> > > for requiring a re-translation of XGXS code back to RS
> > codes at the PCS?
> > >
> > > What is the achitecture, documentation or implementation or
> > other useful reason
> > > for requiring an XGMII between the XGXS and PCS?
> >
> > I simply find it ackward to define a serial PCS encoding as using
> > control codes based on an optional interface. If the XAUI becomes
> > mandatory, then this makes sense. While the XAUI remains optional,
> > I simply can't support this. Obviously, a major disagreement.
> >
> > Ben
> >
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > Walter Thirion wrote:
> > > >
> > > > I don't know about Rich, but I definitely agree with you.
> > The interface on
> > > > each side of XAUI should be XGMII. If the implementer
> > chooses a different
> > > > i/f that is his choice.
> > > >
> > > > Walt
> > > >
> > > > > -----Original Message-----
> > > > > From: Benjamin J. Brown [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
> > > > > Sent: Thursday, March 16, 2000 1:08 PM
> > > > > To: 802.3ae; Rich Taborek
> > > > > Subject: XAUI and 64b/66b
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > > --
> > > > > -----------------------------------------
> > > > > Benjamin Brown
> > > > > Router Products Division
> > > > > Nortel Networks
> > > > > 1 Bedford Farms,
> > > > > Kilton Road
> > > > > Bedford, NH 03110
> > > > > 603-629-3027 - Work
> > > > > 603-629-3070 - Fax
> > > > > 603-798-4115 - Home
> > > > > bebrown@xxxxxxxxxxxxxxxxxx
> > > > > -----------------------------------------
> > > > >
> > >
> > > -------------------------------------------------------
> > > 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
> >
> >
> > --
> > -----------------------------------------
> > Benjamin Brown
> > Router Products Division
> > Nortel Networks
> > 1 Bedford Farms,
> > Kilton Road
> > Bedford, NH 03110
> > 603-629-3027 - Work
> > 603-629-3070 - Fax
> > 603-798-4115 - Home
> > bebrown@xxxxxxxxxxxxxxxxxx
> > -----------------------------------------
> >
XAUI Extend.pdf