Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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@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