RE: Long distance links

["Booth, Brad" <bbooth@xxxxxxxxxx>]

Title: RE: Long distance links

I'd like to address the cost issue.  In a silicon gate count, the MAC for a WAN or a LAN should be the same cost.  As for the PHY, a WAN PHY is going to be more costly than a LAN PHY if you look at the silicon gate count.  The reason for the WAN PHY being more expensive is that the PHY is not only an encoder, it is also a framer.  Where a LAN PHY would perform encoding/decoding and translation from serial-parallel, the WAN PHY must perform all that plus add overhead and perform framing, which adds complexity and cost.

I feel that a WAN PHY and a LAN PHY are required so that LAN implementations are not burdened with the added cost and complexity of overhead and framing that are required to utilize the installed WAN OC-192 base.

Thanks,
Brad

Brad Booth
Austin Design Center
Intel Network Interface Division
 (512) 407-2135 office
(512) 589-4438 cellular

-----Original Message-----
From:   Roy Bynum [SMTP:rabynum@xxxxxxxxxxx]
Sent:   Sunday, September 05, 1999 4:57 PM
To:     NetWorthTK@xxxxxxx
Cc:     stds-802-3-hssg@xxxxxxxx
Subject:        Re: Long distance links




Ed,

I have seen and heard a lot of issue about the WAN compatible MAC/PHY being more
expensive than a LAN only MAC/PHY.  Has anyone done any actual cost analysis?
Having done development work before, even if it was some time ago,  the ability to
use existing technology and chips was always less expensive for initial
deployment. A lower frequency signal encode and decode was always less expensive
over the long term.  Semi-static information processing was always less expensive
was less expensive than active information processing.  Unless it is legacy WAN
vendors trying to protect their control and high profit margins for WAN
interfaces, I can not see why a WAN compatible PHY should be more expensive than a
LAN only PHY at the same laser powers.  I have seen nothing to support it that
assumption.  As a customer, I would like to see the WAN comparable costs to the
LAN interfaces.  As a customer, I would like to be able to take the same type of
interface and use it where ever my implementation architecture requires.  As a
customer I would like to be able to have unmodified 802.3 frames delivered from
any one place to any other place with the least expense, in both equipment and
support costs.

Thank you,
Roy Bynum
MCI WorldCom

NetWorthTK@xxxxxxx wrote:

> Additional Comments:
>
> I think we all brought up good discussions to nail down the specifics to
> enabling decision making.
>
> I agreed Paul's light SONET/PHY (WAN/PHY),  which is the necessary
> requirement to let 10GbE extend its market share into the Global market, and
> to become the dominant force in the marketplace.  A private GbE user in US
> talks to another private GbE user in another continent without slowing down
> to 56K bps, or 112 bps, but at the similar cost, will ultimately wide-open
> the Ethernet market.
>
> However, light SONET/PHY is a low-cost,  intermediate range covneter, which
> is good enough to reach the closest SONET terminal (or DWDM).  The distance
> could be MAN distance, or up to 40 km, which fits Roy's proposal for "Line"
> OAM needs.  The light SONET/PHY data will be retransmitted; as a result, it
> does not have to be responsible for those jitter-tolerance, jitter-transfer,
> ... requirements -- making it as cost-effective as possible.
>
> I believe FP laser can reach 40 km with some good design practices, but not
> much of cost increase from 10 km devices.  Many LAN vendors are supplying 40
> km range without any big-deal, and why we make it so difficult for ourselves?
>
>
> On the other hands, there is no reason at all that MAC/Plus should adapt
> anything other tahn 10.000 Gbps as Dan is screaming to all of us.  Leave it
> as a true Ethernet for backward compatibility, and keep all Ethernet
> advantages.
>
> Some where in the link, the data rate has to be converted.  The light
> SONET/PHY is the most logical and cost-effective location to convert data
> rate and do framing.  We still can make it cheep and works well, because only
> one light SONET/PHY chip is needed at the entering LAN point.
>
> I still do not see the justification of everyone has to be 9,58... , instead
> of 10.000 and 9.58... for the sake of fairness to both LAN and WAN camps.  We
> are an equal opportunity committee -- I believe.
>
> Regards,
>
> Ed Chang
> NetWorth Technologies, Inc.
> EChang@xxxxxxxxxxxxxxxx
> >
>
> Paul,
> >
> >  In your Montreal presentation
> >  (http://grouper.ieee.org/groups/802/3/10G_study/public/july99/bottorff_1_
> > 0799.pdf),
> >  page 5, you show a transponder performing a bridge function between a DWDM
> >  photonic network and a L2/L3 WAN access switch. I have a couple of comments
> >  about this implementation:
> >
> >  1) It seems that you require a very specific SONET WAN PHY on both the
> > Ethernet
> >  side of the Transponder and WAN side of the L2/L3 access switch.
> > Specifically,
> >  you require that the Ethernet frames be scrambled NRZ, that the MAC/PLS
> rate
> > of
> >  at least the switch is 9.58464 Gbps, and that no special symbols be used.
> >  Essentially, your requirement is that the "Ethernet" link PHY is the same
> as
> >  SONET OC-192. Is this not exactly true? If not, please point our my
> >  misconceptions.
> >
> >  2) I'll even go along with you if your answer above is "Yes, IEEE 9.58464
> > GiGE
> >  is really OC-192". As a matter of fact, I'll support it in committee as an
> >  alternative 10 GbE PHY option, call it the "WX" family of PHY's (could be
> >  different wavelengths). However, this PHY is ill suited for the LAN
> > environment
> >  and forces every demarcation point between "old Ethernet" and "new
> SONENET"
> > to
> >  do protocol conversion.
> >  Besides the OC-192 PHY not being cost effective in the LAN for reasons I've
> >  belabored in previous notes to this reflector, an additional cost which
> > cannot
> >  be ignored is the cost/performance penalty assessed by forced protocol
> >  conversion in ALL LAN environments including LAN environments with no WAN
> >  access requirements. Am I wrong about this protocol conversion requirement?
> >
> >  3) It seems to me that your presentation portrays one of many possible
> >  implementations of 10 GbE use in the WAN. The complete set includes WANs
> > which
> >  do and do not utilize DWDM technology. By your own words you indicate that
> > DWDM
> >  equipment may be code dependent (i.e. proprietary). It seems very
> reasonable
> >  then to shield 10 GbE from the special purpose, high cost and proprietary
> >  interfaces such as DWDM. Please help enlighten me as to how standardizing a
> >  non-standard WAN PHY as 10 GbE helps Ethernet customers in general?
> >
> >  4) As far as implementations go, one possible implementation would be to
> > feed
> >  10 GbE at 10.0 Gbps directly into the DWDM photonic network. Since DWDM is
> >  still relatively in its infancy, I foresee more direct WAN implementation
> > which
> >  may benefit from some of the more cost effective PHYs already proposed for
> > 10
> >  GbE, especially if common interfaces are developed for these PHYs. The use
> > of
> >  these PHYs would enable perhaps the most cost effective implementations of
> >  metro and wide area DWDM networks which can STILL tie into the existing WAN
> >  infrastructure via routing or bridging. It's not much of a stretch to
> > envision
> >  WAN access routers with DWDM interfaces on the WAN side and 10 GbE
> > interfaces
> >  on the LAN side. Is this latter implementation impossible? I think not.
> What
> > is
> >  the signaling protocol on the DWDM side in this case? The point here is
> that
> > I
> >  view your DWDM photonic network as only one possible implementation of a
> > DWDM
> >  photonic network. Please don't encumber the rest of the Ethernet community
> > with
> >  implementation specific and special requirements.
> >
> >  I have to apologize for being so harsh in my trying to the bottom of this
> >  issue. But I believe that my strategy in doing so sooner rather than later
> > will
> >  prove to be beneficial. Please also don't take the issues personally. I'm
> >  trying very hard to stick to the issues.
> >
> >  Best Regards,
> >  Rich
> >
> >  --
> >
> >  Paul Bottorff wrote:
> >
> >  > Dan:
> >  >
> >  > I also think we are getting closer to understanding. A few comments.
> >  >
> >  > Cheers,
> >  >
> >  > Paul
> >  >
> >  > At 05:49 PM 9/1/99 -0600, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
> >  > >
> >  > >Paul,
> >  > >
> >  > >While we may not be coming closer to agreement (or maybe we are?) I
> >  > >believe we are at least coming closer to understanding.
> >  > >
> >  > >More in context below...
> >  > >
> >  > >> >So if I understand this model, we have a 10Gig link (campus backbone)
> >  > >> >that is connected to a campus switch. That switch wants to connect to
> >  > >> >a WAN and thus will have a WAN port that operates at 9.58464 by using
> >  > >> >its XGMII "hold" signal.
> >  > >>
> >  > >> 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.
> >  > >
> >  > >This is one point at which we clearly have different perspectives. I
> >  > >believe that there will be sufficient distinction in cost between a
> >  > >DWDM laser for the WAN, and a (WWDM or serial) solution that is
> >  > >limited to a few Km for the campus. Otherwise, why do we need an XGMII?
> >  >
> >  > I agree that a PHY which included a DWDM laser would have a distinct
> >  > identity. However, I don't believe this interface is the current topic of
> >  > standardization. How I see the system being built is that the DWDM
> network
> >  > will be terminated in a shelf which provides 10 GigE access ports. On one
> >  > side of the shelf will be IEEE standard 10 GigE on the other side of the
> >  > shelf will be a DWDM photonic network. The device in the middle at the
> >  > demarcation point will be a transponder/repeater. For a router to access
> >  > the photonic network it will attach a 10 GigE interface to the photonic
> >  > network access port.
> >  >
> >  > A typical 10 GigE WAN link which attaches to a photonic network would be
> >  > built using 3 or more link segments. If you refer to my slides from
> >  > Montreal the 5th slide provides a picture of such a network. The link
> >  > segments which attach from the router to the photonic network need to
> >  > provide the 9.584640 data rate since this is all the data the photonic
> >  > network can carry due to historic reasons. The PHYs in the router do not
> >  > have DWDM photonics.
> >  > >
> >  > >> 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.
> >  > >
> >  > >Actually, there is LX, SX, CX and 1000BASE-T not to mention a few
> >  > >proprietary links for long-haul 1550nm. There is no reason not to
> >  > >believe that 10G will follow the paradigm that allows multiple
> >  > >PHYs for multiple cost/performance domains.
> >  >
> >  > Access to the photonic network described above can (and will in some
> cases)
> >
> >  > be less than 100 meters. It may use 850, 900, 1300, for 1550 nm lasers.
> It
> >  > may be serial or CWDM. Finally it may have a different encode that the
> > DWDM
> >  > network (though I dislike this).
> >  > >
> >  > >> >
> >  > >> >I agree that THAT switch will require buffering to handle the rate
> >  > >> >mismatch, but that would be required in the event that it has more
> >  > >> >than 10 Gigabit links feeding it anyway. This is OK.
> >  > >>
> >  > >> In the configuration I described it is the buffer at a
> >  > >> transponder/repeater
> >  > >> located at the junction between the IEEE segment and the DWDM
> >  > >> segment which
> >  > >> requires buffering to rate match At this juncture there are only two
> >  > >> ports. One side is the IEEE 10.00 Gbps and the other side is
> >  > >> the 9.9584640
> >  > >> Gbps DWDM cloud. The buffer size covers only the rate mismatch not the
> >  > >> normal overload seen in packet switches. The photonic network
> >  > >> appears as a
> >  > >> new segment in the link between switches, not as a separate link.
> >  > >
> >  > >This looks like a specific implementation restriction. I doubt that
> >  > >I would implement it that way.
> >  > >
> >  > >Regards,
> >  > >
> >  > >Dan Dove
> >  > >
> >  > >
> >  > 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
> >
> >  -------------------------------------------------------------
> >  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
> >
> >
> >
> >
> >  ----------------------- Headers --------------------------------
> >  Return-Path: <owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> >  Received: from  rly-yh01.mx.aol.com (rly-yh01.mail.aol.com
> [172.18.147.33])
> > by air-yh05.mail.aol.com (v60.28) with ESMTP; Thu, 02 Sep 1999 17:33:55
> -0400
> >  Received: from  ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by rly-
> > yh01.mx.aol.com (v60.28) with ESMTP; Thu, 02 Sep 1999 17:33:45 -0400
> >  Received:  by ruebert.ieee.org (8.8.8+Sun/8.8.8)
> >   id RAA05567; Thu, 2 Sep 1999 17:25:48 -0400 (EDT)
> >  Message-ID: <37CEEBA3.FB0C9EEC@xxxxxxxxxxxxxxxx>
> >  Date: Thu, 02 Sep 1999 14:26:59 -0700
> >  From: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
> >  Reply-To: rtaborek@xxxxxxxxxxxxxxxx
> >  Organization: Transcendata, Inc.
> >  X-Mailer: Mozilla 4.5 [en] (Win98; I)
> >  X-Accept-Language: en
> >  MIME-Version: 1.0
> >  To: HSSG <stds-802-3-hssg@xxxxxxxx>
> >  Subject: Re: Long distance links
> >  References: <3.0.32.19990902121047.00c65f78@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > com>
> >  Content-Type: text/plain; charset=us-ascii
> >  Content-Transfer-Encoding: 7bit
> >  Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> >  Precedence: bulk
> >  X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> >  X-Listname: stds-802-3-hssg
> >  X-Info: [Un]Subscribe requests to  majordomo@xxxxxxxxxxxxxxxxxx