Re: Long distance links
Rich,
There are two different WAN specific implementation architectures. One of these is
to use one of the SMF PHYs. The other uses a MMF PHY. When going into transport
DWDM equipment at the customer or ISP POP site, the service providers would like to
save money by using inexpensive interfaces also. The 500M MMF PHY is also a WAN
implementation.
Thank you,
Roy Bynum
MCI WorldCom
Rich Taborek wrote:
> Paul Bottorff wrote:
>
> (text deleted)
>
> > Provided people built networks to this configuration, then it works just
> > fine.
> > The IEEE has not yet decided to build 2 PHYs. I believe that the WAN PHY
> > being talked about does not have a distinct identity from the LAN PHY.
> > Because I don't have a good criteria for distinct identity I've found no
> > reason to believe the committee should build 2 PHYs. My assumption is that
> > any PHY developed may run on SMF and may be deployed in the wide area. This
> > is what is currently happening with 1 GigE.
>
> (text deleted)
>
> Paul,
>
> This is exactly what I'm concerned about. Your requirements to have Ethernet
> operate at a MAC/PLS rate of 9.58464 Gbps, perform encoding with NRZ efficiency
> (assumed to mean 0% overhead) and not use special symbols is unreasonable and
> in conflict with virtually all 10 GbE PHY proposals presented to the HSSG to
> date.
>
> The best criteria for distinct identity is cost. For example, we can go through
> all the components in a MAS PHY and all the components in your proposed WAN PHY
> if you like. ...All right... I'll tell you: A prototype MAS PHY transceiver I
> envision will use an SFF shell, a SFF connector, a MAS PHY CMOS chip including
> laser driver, one laser, one photodiode/aIA/Post-amp and operate at 5 GBaud
> (2.5 GHz). The result will be a significant difference in cost with a MAS PHY
> coming out on top.
>
> Another criteria is distance. A MAS PHY at 5 GBaud will support a MMF (all LANs
> are MMF not SMF) distance of approximately 2X your proposed WAN PHY given the
> same optics (which BTW need to support half the bandwidth of a WAN PHY and are,
> therefore, less expensive.
>
> Another criteria is ease of implementation through the use of integral clock
> multiples in the most common 10 GbE equipment. That is, equipment which
> supports multiple Ethernet data rates.
>
> I could go on...
>
> Many PHYs proposed for 10 GbE WILL NOT run over SMF. I'm probably splitting
> hairs here, but VCSELs in general support only MMF. Many of the 10 GbE PHY
> proposals support VCSELs. Are you excluding VCSELs from supporting 10 GbE?
>
> I participated in the Gigabit Ethernet Standards process from day 0 till the
> standard was published. There was never an objective set to support the WAN nor
> was there any discussion or work done on a separate WAN PHY. As you and Roy
> Bynum have pointed out, GbE is being successfully deployed in the WAN without
> even considering this environment. I'm wondering right now if the HSSG should
> do the same at 10 GbE?
>
> Your proposal for a single PHY to meet all HSSG objectives including direct
> support of the SONET WAN environment appears to be flawed from both a
> cost/performance and simplicity perspective. 802.3 folks have drummed these
> basic tenets into my head since I joined the group trying to sell them Fibre
> Channel technology lock stock and barrel. I clearly changed my tune, proving my
> flexibility. We can start negotiating any time now :-)
>
> > Paul A. Bottorff, Director Switching Architecture
> > Enterprise Solutions Technology Center
> > Nortel Networks, Inc.
> > 4401 Great America Parkway
> > Santa Clara, CA 95052-8185
> > Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
> > email: pbottorf@xxxxxxxxxxxxxxxxxx
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------------
> Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
> Principal Architect Fax: 650 940 1898 or 408 374 3645
> Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
> 1029 Corporation Way http://www.transcendata.com
> Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx