Re: XAUI and 64b/66b
Brown, Ben wrote:
>
> 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.
Ben,
On this note, I've been following Jonathan's recommendations and only posting to
the reflector, even when I address an individual directly. This keeps my email
processing to a minimum.
> 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 ;^).
Great! I think we have a deal! at least between us. Here's a proposal from Mr.
Don Alderrou of nSerial for codes for the RS, XGMII and XAUI. I believe that
only the 64B/66B mapping for Idle is missing. Idle would be coded as an
additional 64B/66B 7-bit line code. Hopefully this will keep you from bugging me
except for telling me that my next Guinness is up because I'm a LIGHTWEIGHT ;-)
RS/XGMII RS Code Data Corresponding XGXS/XAUI Codes
Code Name XD<7:0,K> Code name(s)
------------- -------------- -------------------------
DATA (D) xxx xxxxx,0 Dxx.y
IDLE (I) 000 00111,1 K28.5/K, K28.0/R, K28.3/A
SOP (S) 111 11011,1 K27.7/S
EOP (T) 111 11101,1 K29.7/T
ERROR (E) 111 11110,1 K30.7/E
ALT_SKIP (R) 000 11100,1 K28.0/R
ALT_B_SYNC (Kb) 001 11100,1 K28.1/Kb
ALT_unused1 010 11100,1 K28.2
ALT_ALIGN (A) 011 11100,1 K28.3/A
ALT_unused1 100 11100,1 K28.4
ALT_SYNC (K) 101 11100,1 K28.5/K
ALT_unused3 110 11100,1 K28.6
ALT_unused4 111 11100,1 K28.7
ALT_B_SKIP (Rb) 111 10111,1 K23.7/Rb
Best Regards,
Rich
--
> 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@nortelnetworks.com
> -----------------------------------------
-------------------------------------------------------
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@nSerial.com
Santa Clara, CA 95054 http://www.nSerial.com