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

re[2]: Long distance links




Roy,

As a PHY chip guy, the cost basis of the chips in the PMA/PMD will not be significantly different for a LAN vs. WAN implementation.  I even argue against the folks that state that the LAN standards drive a lower cost due to an on chip loop filter.  Last I checked, a pF in an off chip capacitor (ceramic) is a more cost effective way to put pF in a system than adding pF to expensive silicon real estate (or GaAs, InP, SiGe, etc).  But this digresses to details that are secondary to the main point.

The market rewards lower acquisition costs to the item which has both high volume and competition.  Given the standards drive a common interface, a PMA/PMD device shipping in high volume will be driven to a lower cost by competition.  The telecom space today does not have wide multiple sourcing in the PMA/PMD chips, whereas the GE space is basically all multiple sourced.  This has driven the costs down and volumes up.

Let's not forget the element of time.  Our work will enter volume in 2002 to 2005.  Please consider an important tool; semi-log paper.  We need to base our work on what is feasible, but credit the device suppliers with the ability to make as great of gains in the next three years as they have in the past three. The technical boundry conditions may not change, but the learning curve issues will.  This will effect how the various PHYs compete in the future, as the costs of the various PHYs (WWDM, PAM5, Serial scrambled, Serial block coded, VCSELs, tbd other) compete for the different market segments.

I hope that a PHY discussion is launched as a separate discussion, and look forward to a concensus on the speed discussion to permit the group to progress to the coding and other PHY issues.

Regards, Bill


Bill Woodruff				ph: 805 496-7181 x14
GiGA North America Inc.		fax: 805 496-7507
299 W. Hillcrest Dr., Suite 206		woodruff@xxxxxxxxxxx
Thousand Oaks, CA  91360		http://www.giga.dk/

NFOEC, Chicago, Booth 250, September 27-29, http://www.nfoec.com/
ECOC, Nice, Booth 31, September 27-29, http://liszt.enst.fr/ecoc99/accueil.htm


  >>  Dae,

  >>  I have always stated that I, as a customer, needed a WAN compatible 10GbE.
  >>    That includes the
  >>  scramble encoding, the data rate, and the minimal operations support
  >>   functionality.  The
  >>  objectives presented to the HSSG were limited to the MAC data rate only. 
  >>   Without an effective
  >>  9.584 MAC data rate, however it is achieved, there will not be a WAN
  >>   compatible 10GbE.  As a
  >>  customer, I am only one representative of a massive market with a specific
  >>   need.  The WAN/MAN
  >>  market massively enlarged over the LAN only market.  Unless there is a
  >>   specific agenda on the
  >>  part of certain vendors to maintain inflated prices for legacy WAN
  >>   interfaces, there should be no
  >>  reason for a WAN compatible 10GbE to more expensive than the LAN only
  >>   10GbE at the same optical
  >>  output.

  >>  Thank you,
  >>  Roy Bynum
  >>  MCI WorldCom


  >>  Dae Young KIM wrote:

  >>  > Roy,
  >>  >
  >>  > Now we're close to the point. I do agree the line coding can change.
  >>  >
  >>  > But what confuses me is your line of arguments wherein the issue of
  >>   speed(10.0 vs 9.58) and
  >>  > the issue of line coding(Scrambed NRZ) seem to be subtly mixed up, which
  >>   I think shouldn't
  >>  > be. Speed is one thing and Line coding is another.
  >>  >
  >>  > Which one is your primary interest? Are you interested in promoting the
  >>   9.58 speed or the
  >>  > Scrambled NRZ line coding? If it should be the speed, then please stick
  >>   to it, but please
  >>  > don't mix the issue with the line code choice.
  >>  >
  >>  > If I'm not wrong, your latest argument says:
  >>  >
  >>  >     - SONET is coding sensitive. Even DWDM is coding sensitive.
  >>   (Install-base Dark Wavelength
  >>  > and SOENT is using Scrambed NRZ..?)... NRZ efficiency... So we must have
  >>   9.58Gbps speed AND
  >>  > Scrambled NRZ...
  >>  >
  >>  > Here typically, the two things are unnecessarily mixed. Whatever line
  >>   code the WAN infra
  >>  > (Dark Wavelength, DWDM, SONET) may use, just terminate your Ethernet
  >>   stream with Ethernet PHY
  >>  > and get back the MII data stream and feed this into your WAN infra.
  >>  >
  >>  > This so far is one thing: Line Coding
  >>  >
  >>  > And yet, if you're not satisfied with the MII data rate which, say, is
  >>   10.0Gbps, then you
  >>  > proposed a second(WAN-Ethernet) PHY wherein
  >>  >
  >>  >     - the HOLD feature is impelmented
  >>  >     - the line code is, if you like, the NRZ,
  >>  >
  >>  > and ask the Ethernet port at the customer premises Router or Ethernet
  >>   switch to use this
  >>  > WAN-Ethernet PHY. Then this PHY will be very much WAN-infra(Dark
  >>   Wavelength, DWDM, SONET)
  >>  > friendly.
  >>  >
  >>  > The same cutomer premises Router or Ethernet Switch might have
  >>   LAN-Ethernet PHY which might
  >>  >
  >>  >     - not have HOLD feature and so operate at exact 10.OGbps
  >>  >     - use any (yet to be standardized) line code of which NRZ is of
  >>   course yet one of the
  >>  > candidates.
  >>  >
  >>  > This has been another: Speed.
  >>  >
  >>  > Roy Bynum wrote:
  >>  >
  >>  > > Dae,
  >>  > >
  >>  > > The line coding for 100BaseFX is different from 1000BaseSX/LX, that
  >>   did not prevent a
  >>  > > change.  Why should it prevent a change with 10000BaseXX?
  >>  >
  >>  > --
  >>  > Dae Young KIM
  >>  > http://ccl.chungnam.ac.kr/~dykim/