Re: Interface reality check
Rich,
I hate to correct you from your own drawings. The only coding scheme that
you referenced at the PCS in the diagrams was 64B66B! Look at the top of
each drawing. Only the reference drawing does not reference a 64B/66B PCS.
The drawings and your whole discussion is based on the LAN only PHY. As
such it can be ignored by the development of the WAN compatible PHY.
Thank you,
Roy Bynum
----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, April 06, 2000 3:51 PM
Subject: Re: Interface reality check
>
> Roy,
>
> Short answer: No.
>
> Long answer: The drawings referenced represent all 10 GbE proposed PHY's
> including the one I'm assming you're referring to as the "frame stuffed...
WAN
> compatible PHY". XGMII and XAUI/XGXS are proposed as optional interfaces
capable
> of supporting all PCS/PMA/PMD combinations to the best of my knowledge.
The
> drawings clearly illustrate all combinations of XGMII and XAUI/XGXS
supporting
> the PCS/PMA/PMD sublayers.
>
> Best Regards,
> Rich
>
> --
>
> Roy Bynum wrote:
> >
> > Rich,
> >
> > I notice in your drawings, you do not have the frame stuffed PHY as
proposed
> > originally for the WAN compatible PHY. Does this mean that your
proposals
> > here are for the LAN only PHY specifically and not other PHYs?
> >
> > Thank you,
> > Roy Bynum
> >
> > ----- Original Message -----
> > From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
> > To: HSSG <stds-802-3-hssg@xxxxxxxx>; David Law <David_Law@xxxxxxxx>;
> > Benjamin J. Brown <bebrown@xxxxxxxxxxxxxxxxxx>
> > Sent: Friday, March 31, 2000 6:55 PM
> > Subject: Re: Interface reality check
> >
> > > Ben,
> > >
> > > Attached to this note is a PDF file containing a proposal to modify
the
> > > Reconciliation Sublayer to enable the transport of data and control
codes
> > in a
> > > PCS and XAUI independent manner. The proposal contains a reference 10
GbE
> > > implementation and multiple examples of code translation between two
10
> > GbE
> > > devices, Device A and Device B. It took too long to draw the figures
in
> > ASCII
> > > and the end result was ugly, so I resorted to PowerPoint. The proposal
can
> > be
> > > described in the following simple terms:
> > >
> > > - The XGXS transmitter translates Idle /I/ to XAUI Idle /A/K/R/;
> > > - The RS receiver translates /A/K/R/ to /I/;
> > > - The XGMII, XAUI/XGXS, PCS, PMA and medium transport all RS codes
> > > transparently.
> > >
> > > It is likely that the attached file is too large for this reflector,
so
> > you may
> > > either not receive this note at all, or the file associated with it
will
> > not get
> > > through. If this happens, I'd like to request Mr. David Law to post
the
> > attached
> > > file to the "email_attach" directory at:
> > > http://grouper.ieee.org/groups/802/3/10G_study/public/email_attach/
> > >
> > > I'll monitor this reflector for the fate of this note and the attached
> > file.
> > >
> > > Additional comments below:
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > Brown, Ben wrote:
> > > >
> > > > Rich,
> > > >
> > > > See comments below:
> > > >
> > > > Rich Taborek wrote:
> > > > >
> > > > > The issue is not whether XAUI encodings are required for 64B/66B,
the
> > issue is
> > > > > whether either the MAC needs to signal the PHY with anything other
> > than Idles or
> > > > > the PHY itself needs to signal over the medium.
> > > >
> > > > Agreed.
> > > >
> > > > > I completely forgot about the obvious case of ERROR, where the MAC
> > transmitter
> > > > > or the PHY at any point in the link needs to replace a data or
control
> > code with
> > > > > an ERROR code. In order to support this proposed function, 64B/66B
> > must
> > > > > transport /E/ codes in addition to /I/ codes across the medium.
> > > >
> > > > Of course, and don't forget /S/, /T/ and /D/.
> > > >
> > > > > Note that Gigabit Ethernet also signals Break Link and Remote
Fault
> > through the
> > > > > use of Config words, which are essentially a control encoding
> > different than the
> > > > > GbE idle stream. Several folks including Mr. Howard Frazier and
myself
> > have
> > > > > already alluded to the benefit and compatibility of supporting
Break
> > Link and
> > > > > Remote Fault for 10 GbE.
> > > >
> > > > This is a good example of codes in addition to those required by the
> > > > MAC/RS. So this means there is precedent to send information across
the
> > > > link other than that information which comes from/to the MAC via the
RS.
> > > > However, these codes are only used as a startup (Auto-Neg) or to
> > > > signal error conditions (remote fault & break link). They are not
> > > > present between every packet.
> > >
> > > I agree to the first part of the paragraph above. However, the
> > architecture and
> > > implementation for the MAC and PHY to initiate, transport and receive
> > control
> > > information other than Idle and Packets is intimately intertwined with
> > Idle and
> > > Packet information. In fact, Ethernet can be considered to be an Idle
> > stream
> > > transport which is rudely interrupted to transport Packets, Initialize
the
> > link,
> > > or report Errors.
> > >
> > > I'm not sure I understand either the relevance or accuracy of your
> > statement
> > > that: "They (codes) are not present between every packet." Control
> > information
> > > may indeed be required between every packet (e.g. Rate Control, Error,
> > etc.) The
> > > fact that control information transport may be required between ANY
packet
> > is
> > > relevant.
> > >
> > > > > This makes for a potential requirement to signal at least three
> > control codes
> > > > > besides /I/, /T/, /S/ and /D/ across 64B/66B and the medium. A
further
> > > > > requirement is to support the transport of these codes through the
> > optional
> > > > > instantiations of the PCS Service interface.
> > > >
> > > > I agree that these codes may need additional encoding to go across
> > > > something such as XAUI. I don't agree that this additional coding
> > > > cannot be removed at the end of the XAUI.
> > >
> > > Major disconnect. The "three control codes" mentioned above are: Break
> > Link,
> > > Remote Fault and Error. These codes cannot be removed at the end of
XAUI
> > (I
> > > assume that you mean by the XGXS) since the codes are destined for
either
> > the
> > > PCS or the RS. In the case that the destination is the PCS, the PCS is
> > > responsible for transporting these codes over the medium to the remote
> > link end.
> > > In the case that the destination is the RS, the XGXS is responsible
for
> > > transporting these codes over the XGMII, if present, or directly
> > delivering the
> > > codes to the RS. It should be clear that these codes cannot be removed
by
> > > XAUI/XGXS unless a trap for a specific code is specified. Am I
completely
> > > misinterpreting your response?
> > >
> > > > > One way I'll propose to do this cleanly is to have the RS receiver
> > treat /A/K/R/
> > > > > the same as /I/. In fact, all codes other than /T/, /S/, /D/ and
/E/
> > could be
> > > > > treated as /I/ by the RS receiver until those other codes are
defined
> > by 10 GbE.
> > > > >
> > > > > No translations by the PCS, including 64B/66B, would be necessary.
> > > >
> > > > It's not a matter of this translation being necessary. I keep
getting
> > > > the feeling that you're trying to make the PCS "easier" by "keeping"
> > > > the /A/K/R/ rather than converting them back to /I/. If all
> > > > implementations used XAUI than this could indeed be considered
> > > > "easier". However, if we're not going to force the use of XAUI then
> > > > "keeping" /A/K/R/ is not necessarily "easier". Am I reading you
> > > > incorrectly? (The above quotes are for emphasis. They are not meant
> > > > to imply that you've used these words.)
> > >
> > > I believe that we both made very good points in this thread about the
> > > practicality and impracticality of performing code conversion required
to
> > > support optional interfaces. You are reading me to a "tee" by saying
that
> > I am
> > > trying to make the PCS easier. I am trying to make the entire PHY as
> > simple as
> > > possible by considering the requirements and flexibility of all
elements.
> > I
> > > think you'll find the attached proposal to your liking :-)
> > >
> > > > > Whaddya think?
> > > >
> > > > I'll reserve judgement until I see the full proposal.
> > > >
> > > > Ben
> > > >
> > > > --
> > > > -----------------------------------------
> > > > Benjamin Brown
> > > > Router Products Division
> > > > Nortel Networks
> > > > 1 Bedford Farms,
> > > > Kilton Road
> > > > Bedford, NH 03110
> > > > 603-629-3027 - Work
> > > > 603-624-4382 - 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
>
>