Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Interface reality check


The real issue is that, as I understand it, there is no need to make major
changes to the PCS interface if XAUI is considered as only an XGMII
extender.  Adding XGXS as part of the PCS interface, as I understand it, is
what will require some major changes.  The XGMII/XAUI/XGMII relationship and
technical description can be an annex, not part of the PCS interface clause.
All of the other variants of XGMII/XAUI/XGXS will require major alterations
to the clause that defines the RS/PCS interface, particularly the residue of
non-Ethernet symbols that are precoded to the PCS.

Thank you,
Roy Bynum

----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, March 30, 2000 5:40 AM
Subject: Interface reality check

> Walt, Rick, Ben,
> There seems to be quite a bit of confusion on several issues and I'm
trying very
> hard to listen to all the viewpoints. However, some of them seem fairly
> impractical to me. Among those are the following:
> 1) XAUI with XGMII on both sides:
> I've discussed this issue on the reflector in detail, especially with Mr.
> Brown, Nortel. In one of our latest communiqué's, Ben agreed with my view
> the various physical instantiations of the PCS Service Interface:
> > "I fully agree that a XAUI interconnect scheme does not require
> > an XGMII interconnect. I fully agree that, though the IEEE 802.3ae
> > Layer Diagram proposed by Mr. Brad Booth shows both of these
> > interconnect "layers", it does not mean both must be implemented.
> > Indeed, because they are both optional, an implementation could
> > actually choose to invent a completely different one and use it.
> > (BTW, I followed your analogy - I'd throw away that 15' cord and
> > just use the heavier one.)" - Mr. Ben Brown, 3/19/00
> - The XGMII is proposed as an optional physical instantiations of the PCS
> Service Interface;
> - The XAUI/XGXS is proposed as an optional physical instantiations of the
> Service Interface;
> - Neither, either or both XAUI may exist;
> - In fact, more than two instances of XGMII and/or XAUI/XGXS may be
> within a single Ethernet device. For example, the suggestion of XAUI "in
> middle of the XGMII" would architecturally be represented as three
> instantiations of the PCS Service interface, two XGMII's and one
> - A compliant Ethernet device implementation may likewise include three
> and two XAUI/XGXS's.
> My point is that "XAUI as a XGMII extender" is not an architectural
> would be difficult to document, and represents only one possible compliant
> implementation.
> I envision cost effective 10 GbE devices implementing the following
> between the RS and PCS either:
> a) XGMII with no XAUI/XGXS; or
> b) XAUI/XGXS with no XGMII; or
> c) XGMII attached to XAUI/XGXS.
> I'd like to propose that we drop the use of the term "XGMII extender" in
> reference to XAUI/XGXS as it is architecturally meaningless and confusing.
> Please instead focus on filling out the architectural support necessary to
> support the two proposed optional physical instantiations of the PCS
> Interface in any combination.
> --
> 2) Transport of non Idle codes across the medium:
> I'm all for architecting 10 GbE in the simplest possible fashion while
> all HSSG objectives and related requirements. An issue has been raised as
> whether it is necessary for the 10 GbE device to signal and codes other
> Idles across the medium. Once again, in a recent communiqué between Mr.
> Brown and myself, I pointed out several reasons to transport non idle
> across the medium. These reasons are typical and atypical and include the
> following:
> a) Support of "Remote Fault" and "Break Link" capabilities to enable
> failover of a broken link to an alternate link, if available. This
> exists at other Ethernet speeds and is an extremely useful link management
> function. This functionality can be considered a basic OAM&P function;
> b) Support of Open Fibre Control protocols which may enable longer link
> distances resulting from the ability to safely increase transmitted
> power;
> c) Support of Layer 1 signaling for Optical Cross-Connects and management.
> item essentially provides native Ethernet WAN links with the equivalent of
> for SONET. It is clearly complimentary to HSSG objectives to support the
WAN and
> 40+ km links. Note that I have raised serious technical questions about
> whether the WAN PHY is capable of cost effectively meet the requirements
> Ethernet device and equipment design based on the requirement to perform
> re-framing whenever clock tolerance compensation is required. This is not
> case with the LAN PHY. A consequence of this issue is that the WAN PHY
> requirement satisfied by SONET framing may need to be accommodated instead
> the LAN PHY in a manner similar to that described by this item;
> d) A desire for common components with Fiber Channel, InfiniBand, etc.
> Basically, Ordered-Sets may be supported as an optional Layer 1 signaling
> for FC, InfiniBand and other protocols and not affect 10 GbE. If and when
> layer 1 signaling function is required for 10 GbE it can simply be enables
> without "re-spinning" components. Transparent support for such functions
> be tantamount to treating unrecognized control codes as Idles as is
> the case for the 1 Gigabit Ethernet PCS Receive state machine.
> Support of any of the above items requires the transport of non Idle codes
> across the medium. This support is already provides in the existing RS,
> XAUI/XGXS and 64B/66B proposals. I propose the that these functions be
> maintained and exploited only to the extent to provide the level of
> required to provide a robust 10 GbE architecture for the LAN, MAN and WAN.
> I have a few more comments interspersed in the referenced note below:
> Rick Walker wrote:
> >
> > Dear Walter,
> >
> > >  Walter Thirion <wthirion@xxxxxxxxxxxx> writes:
> > > I'm slightly confused by your comment:
> > > > Rich Walker wrote:
> > > > All PMD's could take their input from pure XGMII and convert back to
> > > > XGMII at their output.  It makes no sense to burden all the PMDs
> > > > complex rules for converting between the idiosyncrasies of
> > > > other coding
> > > > schemes.
> > >
> > > I'm not sure how this fits with the PMD.
> >
> > Not surprising.  I admit to using the terms wrongly.  Perhaps it would
> > be better if I said PCS rather than PMD.  I'm relatively new to the
> > precise but arcane nomenclature of 802.3.  One nice side effect of this
> > discussion is to help me to tighten up my use of the language.
> >
> > > I do agree that XGMII should be the specified interface between the
> > > MAC/RS and the PCS.  Further, if we treat XAUI as an XGMII extender,
> > > then XAUI should take in XGMII and spit it back out the other side
> > > (maybe 20" of copper later...).
> >
> > Exactly.
> Why Rick? Are you proposing that the XGMII as a MANDATORY interface
between the
> XGXS and PCS? If so, what purpose does this serve except to increase 10
> product cost?
> > > On the other hand, if XAUI is to be used between the PCS and the PMA,
> > > then its inputs and output can be whatever the group thinks is the
> > > best signalling interface between those layers, but by definition
> > > (since it would be below the PCS), in this instance XAUI would be
> > > transporting whatever coding the PCS used.  But even this could be
> > > done with an envelope as opposed to a decode/recode.
> >
> > Every layer, in addition to any layer-specific function, must at least
> > transmit logical Ethernet signalling information.
> >
> > XGMII is perhaps the most succinct specification of a pure-logical
> > signalling layer.  (please pardon my non-standard language here...)
> >
> > What I'm trying to say is that any idiosyncratic PCS coding of a
> > PMD should never need to be supported by the PCS of any other PMD-style.
> >
> > Any /A/ columns or scrambled idles used by XAUI should stop at the XAUI
> > boundary.  The 64b/66b serial PCS/PMD has no business accepting or
> > transmitting these codes.
> I believe that you are missing the point here. If 64B/66B needs to
> codes other than /I/ for any reason, then 64B/66B it should. I don't have
a big
> problem with converting /I/ to an /A/K/R/ stream and vice-versa and
> that these conversions may be necessary for some implementations. However,
> is an IMPLEMENTATION issue.
> The question back to you is what about 64B/66B transporting codes other
than /I/
> generated at the Reconciliation Sublayer?
> Also, 64B/66B is not even currently defined to transport /I/, it is only
> to transport /A/K/R/. I'll propose the transport of /I/ in 64B/66B in a
> note.
> > This is easy to see if you are willing to view XAUI as a copper PCS/PMD.
> > It should, like all the other physical transmission systems be defined
> > w.r.t.  the lowest common denominator of logical Ethernet signalling:
> > eg: XGMII.
> The XGMII is proposed as an optional interface. Since when did it become
> Ethernet's LCD?
> > In this way, all PCS/PMD combinations act as simple logical XGMII
> > extenders, whether 20 inches over copper, or 40 km over fiber, or at
> > several variants in cascade.
> I think you mean "instantiations of the PCS Service interface" instead of
> "PCS/PMD combinations". Notwithstanding, coding requirements are different
> different CODECs that's why we have an /I/ to /A/K/R/ translation.
However, this
> translation is simple and straightforward, as long as it's not required 10
> in one 10 GbE device.
> > kind regards,
> > --
> > Rick Walker
> --
> Best Regards,
> Rich
> -------------------------------------------------------
> 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