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