Re: XAUI and 64b/66b
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