Re: Interface reality check
Rich,
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.
Ben
> Brown, Nortel. In one of our latest communiqué's, Ben agreed with my view
of
> 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
PCS
> Service Interface;
> - Neither, either or both XAUI may exist;
> - In fact, more than two instances of XGMII and/or XAUI/XGXS may be
implemented
> within a single Ethernet device. For example, the suggestion of XAUI "in
the
> middle of the XGMII" would architecturally be represented as three
physical
> instantiations of the PCS Service interface, two XGMII's and one
XAUI/XGXS;
> - A compliant Ethernet device implementation may likewise include three
XGMII's
> and two XAUI/XGXS's.
>
> My point is that "XAUI as a XGMII extender" is not an architectural
construct,
> would be difficult to document, and represents only one possible compliant
> implementation.
>
> I envision cost effective 10 GbE devices implementing the following
interfaces
> 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
Service
> 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
meeting
> all HSSG objectives and related requirements. An issue has been raised as
to
> whether it is necessary for the 10 GbE device to signal and codes other
than
> Idles across the medium. Once again, in a recent communiqué between Mr.
Ben
> Brown and myself, I pointed out several reasons to transport non idle
codes
> across the medium. These reasons are typical and atypical and include the
> following:
>
> a) Support of "Remote Fault" and "Break Link" capabilities to enable
timely
> failover of a broken link to an alternate link, if available. This
capability
> 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
support
> distances resulting from the ability to safely increase transmitted
optical
> power;
>
> c) Support of Layer 1 signaling for Optical Cross-Connects and management.
This
> item essentially provides native Ethernet WAN links with the equivalent of
OAM&P
> 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
the
> whether the WAN PHY is capable of cost effectively meet the requirements
of
> Ethernet device and equipment design based on the requirement to perform
SONET
> re-framing whenever clock tolerance compensation is required. This is not
the
> case with the LAN PHY. A consequence of this issue is that the WAN PHY
OAM&P
> requirement satisfied by SONET framing may need to be accommodated instead
by
> 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
method
> for FC, InfiniBand and other protocols and not affect 10 GbE. If and when
a
> layer 1 signaling function is required for 10 GbE it can simply be enables
> without "re-spinning" components. Transparent support for such functions
would
> be tantamount to treating unrecognized control codes as Idles as is
currently
> 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,
XGMII,
> 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
support
> 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
with
> > > > 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
GbE
> 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
Ethernet
> > signalling layer. (please pardon my non-standard language here...)
> >
> > What I'm trying to say is that any idiosyncratic PCS coding of a
particular
> > 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
transport
> 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
understand
> that these conversions may be necessary for some implementations. However,
this
> 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
defined
> to transport /A/K/R/. I'll propose the transport of /I/ in 64B/66B in a
separate
> 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
for
> 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
times
> 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 http://www.nSerial.com