Re: XAUI and 64b/66b
Rick Walker,
I need to apologize to you. I've been having this conversation
with Rich Taborek as if it is his proposal and not including
you. Please, accept my apology and chime in any time with your
opinion.
Rich,
Wonderful! I agree with you completely. This means the transmit
PCS simply 64b/66b encodes the information it gets from the MAC
service interface, be this information in the form of XGMII
encodings or XAUI encodings. The receive PCS must have the
intelligence to know whether its MAC service interface requires
XAUI encodings or XGMII encodings. It simply 66b/64b decodes
the information then may pass the data straight through or
convert it to XAUI or XGMII, whichever is applicable.
I think this would be a great addition to the 64b/66b proposal
for the next meeting. Add to that an explicit mapping of the
bit ordering through the entire PCS and I think I might stop
bugging you both (at least until I actually see the proposal,
that is ;^).
Thanks,
Ben
Rich Taborek wrote:
>
> Ben,
>
> Comments interspersed below (it's easier).
>
> Brown, Ben wrote:
> >
> > Rich,
> >
> > There seem to be a couple of "non-typical" reasons why
> > we want to carry the XAUI encoding across the 64b/66b, in
> > particular a & b below. I'd like to see more on c & d
> > before I pass judgement on whether these functions require
> > XAUI encoding to be supported.
>
> I believe that (b) may end up being typical as I am starting to see technical
> problems with a SONET based WAN PHY (see my clock tolerance note) and we clearly
> have an objective to support the WAN, whether or not it is SONET. A 40 km
> solution is a WAN solution and requires OAM & P, irrespective of whether that
> OAM & P is SONET or different and simply meets OAM & P requirements. (b)
> addresses this issue or at least highlights the issue. Things would be much,
> much simpler if the PAR did not include in its purpose: "to expand the Ethernet
> application space to include Wide Area Network links".
>
> > Rich Taborek wrote:
> > >
> > > Support of control information during the IPG for Ethernet. This would include:
> > > a) Desirability for common components with FC, InfiniBand, etc.;
> > > b) Support of Layer 1 signaling for Optical Cross-Connects and management
> > > thereof ala Mr. Osamu Ishida's Albuquerque proposal;
> > > c) Support of Layer 1 signaling enabling functions such as Remote Fault and
> > > Break Link to allow the prompt failover protocols (e.g. Busy Idle or
> > > Ordered-Sets);
>
> Mr. Howard Frazier suggests using Busy Idle for Remote Fault signaling and a
> standalone single code for Break Link. These would have to be signaled
> end-to-end and transported by the XGMII, XAUI, PCS, PMA, PMD, medium, PMD...
>
> I'm leaning instead towards Ordered-Sets since they are more flexible and
> capable of addressing items (b) and (d) on this list with no additional link
> protocol.
>
> > > d) Possible support of Open Fibre Control protocols;
>
> I have had no time to work on this. However, it will require end-to-end
> signaling and protocol at the Physical Layer. Since there is little
> "intelligence" below the PCS, the signaling and protocol would likely reside in
> the PCS layer or above AND a corresponding Management sublayer.
>
> > > e) Support of XAUI codes in the absence of the XGMII without having to revert
> > > to RS codes.
> >
> > As for e (above), this wouldn't be necessary if my proposal was
> > supported. What I'm saying is:
> >
> > Transmit PCS supports either XAUI or XGMII encodings.
>
> I agree with this. Its always easier to speak than to listen :-)
>
> > Receive PCS must be able to interpret both encodings and optionally
> > convert XAUI encodings to XGMII encodings if an XGXS is not present
> > at the interface or convert XGMII encodings to XAUI encodings if an
> > XGXS is present at the interface. Perhaps some of these functions
> > are supported by the XGXS itself, that depends on where we draw the
> > line in writing the standard.
>
> I agree with your Rx PCS description also. Now you see the dilemna! Do we have
> some kind of communication going between the Rx PCS and the Tx XGXS, unspoken in
> layer speak, or do we do something silly like having the Rx PCS convert the XAUI
> codes to XGMII and then have the Tx XGXS regenerate XAUI codes from the received
> XGMII codes.
>
> The only thing I disagree with is a REQUIREMENT to implement the XGMII between
> the PCS and XGXS. The writing of the standard should not basterdize
> straightforward implementations.
>
> > Are you in support of such a method or is your position that 64b/66b
> > should always carry XAUI encodings only, regardless of whether a
> > XAUI is present? Presumably, if this is your position, then the
> > transmit PCS (when there is no XAUI present) would have to support
> > all the randomness in regards to /A/ and /R/ that you're proposing
> > so at the receive side, should a XAUI be present, the translation
> > from 64b/66b to XAUI is direct.
>
> It seems to me that the simplest solution from an implementation and
> documentation perspective is to define 64B/66B to transport XGMII as well as
> XAUI codes. Any and all code conversions would be implementation dependent.
>
> > Thanks,
> > 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
> > -----------------------------------------
>
> --
>
> 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
--
-----------------------------------------
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
-----------------------------------------