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

RE: XAUI, SFF connectors




Roy,

We do not always have the luxury of having a "mature" technology
available to meet our needs. At times in the past, 802.3 has been
able to use a mature technology (e.g. borrowing physical layer
technology from Fibre Channel for Gigabit Ethernet). At times
we have had to develop our technology from scratch (e.g. designing
a 10 Mbit/s transceiver for wire spec'ed only up ~10 KHz for 
10BASE-T). We do what we need to do and we have applied a level
of skill that makes it work. 

Even when picking up a mature technology, one needs to do work
on fitting it into ones application. Fibre Channel was shipping
8B/10B long before we standardized it, but a lot of 802.3z people
hours had to be applied to getting the jitter specs right.

XAUI is not mature (in the sense of having shipping products). 
But it is well understood and based on technology we have used 
before. Since the Infiniband spec for its equivalent of XAUI 
is written and undergoing the end of its review process, there
is no validity to your assertion that .3ae is defining it 
so that other technologies can use it. Infiniband has a fully
defined stripping method. IEEE 802.3ae and InfinibandTA have
chosen somewhat different designs for their stripping, so each
group is working out the details for themselves.

We adopted XAUI in Ethernet because it met Ethernet needs. I'm 
firmly convinced that it will make our technology cost less,
not more as you continue to assert. It will provide an efficient
way to connect components and by being standardized, it will let
a wide variety of PMDs and Link layer components interoperate. 

Why are you still argueing about this? We voted overwhelmingly
to adopt XAUI.

Pat

-----Original Message-----
From: Roy Bynum [mailto:rabynum@mindspring.com]
Sent: Thursday, July 27, 2000 2:55 PM
To: stds-802-3-hssg@ieee.org
Subject: Re: XAUI, SFF connectors



Ali,

You may have it backwards.  XAUI is not presented as a back plane 
technology.  XAUI is presented as a copper etch extension contained only on 
the PCB.

The people that would be benefiting from the technology sharing is Fibre 
Channel and Infiniband.  At present, those groups do not have any mature 
technology at 10Gb.   Have you not noticed the reflector traffic discussing 
how this technology should be developed. If Fibre Channel and Infiniband 
had demonstrated 10Gb parallel interfaces already, then it would be a 
different situation.   The original presentations on "Hari" and then "XAUI" 
would have been very different; they would have referenced previous 
implementations. If it were mature technology from the other environments, 
then the questions of "striping" and "jitter" would have been answered 
already and not be topics of discussion here.  The fact that these are 
topics of discussion is another proof that it is P802.3ae that is paying 
for this and the other technologies are the actual beneficiaries.

It will be P802.3ae that will be paying for the technology development and 
go through the "growing pains" to mature the technology.   As a customer, I 
find paying for the development of a technology specific for other markets 
to be difficult to accept in order to get the technology that I do want and 
am willing to pay for.  I also find it uncomfortable and insecure to 
attempt to depend on a technology that does not have a development and 
maturation history.

Thank you,
Roy Bynum

At 09:03 AM 7/26/00 -0700, ghiasi wrote:

>Hi Roy
>
> > X-Sender: rabynum@pop.mindspring.com
> > Date: Mon, 24 Jul 2000 14:26:27 -0500
> > To: ghiasi <Ali.Ghiasi@eng.sun.com>
> > From: Roy Bynum <rabynum@mindspring.com>
> > Subject: Re: XAUI, SFF connectors
> > Mime-Version: 1.0
> >
> > Ali,
> >
> > I agree, it should be possible to put more than one 10GbE port on a PCI
> > form factor.  I agree, XAUI is a good technology to get from the
backplane
> > to the ASIC.
>
>How do you expect 10Gig Ethernet data is getting from ASIC through
>backplane and to the I/O?
>
> >What I object to is hijacking the Ethernet standard to
> > develop technology that is not for Ethernet, but for generic system 
> vendors
> > using Infeneband and Fibre Channel.
>
>Gigabit Ethernet physical layer was based on Fiber Channel, it is called
>leveraging or cost amortization.  Also Infeneband is written as 
>"Infiniband".
>
> >If possible, I am going to make the
> > XAUI people pay for their pushing the cost of that technology
development
> > into the P802.3ae standard.
>
>Since we are going to save you some buck, I hope you don't mind instead
>you paying us.
>
>Thanks,
>
>Ali Ghiasi
>Sun Microsystems
>
> >
> > Thank you,
> > Roy Bynum
> >
> > At 10:33 AM 7/24/00 -0700, you wrote:
> > >Hi Roy
> > >
> > > > X-Sender: rabynum@pop.mindspring.com
> > > > Date: Mon, 24 Jul 2000 11:23:15 -0500
> > > > To: rtaborek@earthlink.net, HSSG <stds-802-3-hssg@ieee.org>
> > > > From: Roy Bynum <rabynum@mindspring.com>
> > > > Subject: Re: XAUI, SFF connectors
> > > > Mime-Version: 1.0
> > > > X-Resent-To: Multiple Recipients
<stds-802-3-hssg@majordomo.ieee.org>
> > > > X-Listname: stds-802-3-hssg
> > > > X-Info: [Un]Subscribe requests to  majordomo@majordomo.ieee.org
> > > > X-Moderator-Address: stds-802-3-hssg-approval@majordomo.ieee.org
> > > >
> > > >
> > > > Rich,
> > > >
> > > > What need does an interface card have for SFF connectors that can 
> only put
> > > > one optical port within a 13 inch copper etch radius?
> > >
> > >It should be very reasonable to put two to four 10 Gig port on a PCI
form
> > >factor card.
> > >
> > > From what you and
> > > > others are making us believe, the form factor requirements for 10GbE
> > > are so
> > > > large that SFF connectors are a non-issue.  If 10GbE interfaces are 
> going
> > > > to be so dense that we will need SFF connectors, why did we need 
> XAUI?  I
> > > > can't see how you would need both.
> > >
> > >XAUI provides high through put 3.125 Gb/s from two ASIC pin (+ few
extra)
> > >with very flexible interconnect, while keeping the package pin count
> > >reasonable.  XAUI is the high bandwidth pipe to get data to and from
> > >your big ASIC.
> > >
> > >The other reason for XAUI was to define an interface for the backplane
> > >and ASIC so they can be developed, while everyone is arguing on the
> > >right PMD for 10 gig.
> > >
> > >Thanks,
> > >
> > >Ali Ghiasi
> > >Sun Microsystems
> > >
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > > At 10:13 PM 7/23/00 -0700, Rich Taborek wrote:
> > > >
> > > > >Roy,
> > > > >
> > > > >As is usually the case, you always bring up interesting tangential
> > > > >issues in your email. This time it's:
> > > > >
> > > > >"Given the form factor that would use XAUI, SFF connectors would 
> not be
> > > > >a requirement."
> > > > >
> > > > >What in the world does the XAUI interface, specified for use as an 
> XGMII
> > > > >extender, have to do with SFF connectors???
> > > > >
> > > > >Please enlighten me.
> > > > >
> > > > >Best Regards,
> > > > >Rich
> > > > >
> > > > >--
> > > > >
> > > > >Roy Bynum wrote:
> > > > > >
> > > > > > Chris,
> > > > > >
> > > > > > I am not sure of your comment about LC having a proven track 
> record
>for
> > > > > > single mode implementations.  At present, WorldCom has not 
> deployed
>any
> > > > > > LC.  All of the connectors currently specified for SM 
> installations is
> > > > > > SC.  A particular vendor is attempting to get WorldCom to make 
> use of
> > >their
> > > > > > connectors.  ( I will not say how successful or not they are.
> > > )  Several
> > > > > > system vendors are attempting to make use of LC, but at present,
> > > none have
> > > > > > been certified.  Given the form factor that would use XAUI, SFF
> > > connectors
> > > > > > would not be a requirement.
> > > > > >
> > > > > > Thank you,
> > > > > > Roy Bynum
> > > > > >
> > > > > > At 04:28 PM 7/21/00 -0600, Chris Simoneaux wrote:
> > > > > >
> > > > > > >Our opinion is that LC is a better connector than MTRJ.  The LC
> > > does not
> > > > > > >seem to suffer the possible damage that MTRJ can see with high
> > >mate/demate
> > > > > > >cycles...due to the guide pin action.  Also, the LC has a
proven
>track
> > > > > > >record for singlemode whereas the MTRJ does not.
> > > > > > >
> > > > > > >PS: My feeling is the standards body's charter should be to 
> specify a
> > > > > > >connector. However, there's too much rhetoric in the procedure.
> > > Therefore
> > > > > > >it's difficult to choose the best solution.  Inevitably the
real
> > > winner/s
> > > > > > >will come forward. Conclusion: Choose a connector at the
standards
> > > > > level as
> > > > > > >it can expose good points of each solution.
> > > > > > >
> > > > > > >Chris Simoneaux
> > > > > > >Picolight
> > > > >
> > > > >-------------------------------------------------------
> > > > >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
> > > >
> >