Re: Interface reality check
Ben,
Thanks for your straightforward opinion and analysis of physical intantiations
of the PCS Service interface. We are in complete agreement here. Sorry for
changing topics, but it wasn't me that started tying the two together ;-)
Hopefully the interface issue is now settled once and for all
--
Best Regards,
Rich
--
"Brown, Ben [BAY:NHBED:DS48]" wrote:
>
> Rich,
>
> There seems to be 2 separate issues in your message: the physical
> instantiations and the IDLE encodings across the PCS. I think we
> should be able to put the first issue to bed.
>
> The physical instantiation can be XGMII, XAUI, both or neither or
> anything else anyone wants for that matter. It should not be part
> of the standard to force any implementation on anyone. These are
> optional instances and have 2 different purposes:
> - The XGMII is defined because it is a simple, straightforward
> representation of the information supplied and needed by the
> Reconciliation Sublayer. We'll probably hang an electrical
> specification on it so it can reasonably be implemented but it
> is not a requirement for anyone to do so;
> - The XAUI is defined because it enables a reasonable distance
> between components on the PCB and is designed to carry all
> information supplied and needed by the RS by encoding that
> data further taking into account realities of this interface
> such as the alignment problems (comma alignment as well as
> lane alignment) and EMI concerns. Again, an electrical
> specification is being associated with this interface so it
> can reasonably be implemented but it is not a requirement for
> anyone to do so.
>
> The real issue of my original question and all these subsequent
> messages has been the content of the information encoded by the
> PCS. The first issue has continued to bounce back up because we
> are all not perfect in our nomenclature. I suggest that in the
> future, if someone has a concern about the possible physical
> instantiations, they start a new thread (as some have already
> done with the electrical specs for an XGMII). If someone is
> responding to this thread it is in the interest of discussing
> the topic of encodings and not the physical instantiations and
> if someone uses the wrong nomenclature, we all need to be a
> little patient and not assume that they want to change the
> interfaces.
>
> That was kind of long so I'll make further comments in a separate
> email to keep the topics separate.
>
> Ben
>
> Rich Taborek wrote:
> >
> > 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
> --
> -----------------------------------------
> 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