Re: re: Long distance links
I would like to support Bill's statement that the WAN vs LAN cost issue appears
to have more to do with competition, volumes, and multiple sourcing than the
underlying relative complexity of the technologies involved. I would also add
that the 802.3 standards process does help this business factor since it opens
up the component value chain to multiple vendors.
Manager, Business Development
Bill Woodruff <woodruff@xxxxxxxxxxx> on 09/07/99 10:24:45 AM
Sent by: Bill Woodruff <woodruff@xxxxxxxxxxx>
cc: HSSG <stds-802-3-hssg@xxxxxxxx> (Bruce Tolley/HQ/3Com)
Subject: re: Long distance links
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.
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
>> 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
>> 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/