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