Re: Long distance links
Bruce,
I can't possibly agree with your last statement (about the beer consumption :-), but
I agree with everything else you say.
I'm perfectly happy to consider any HSSG objectives which have Ethernet moving into
the WAN. I'm also perfectly happy to be educated about WAN requirements and exactly
how WAN access methods like SONET/SDH meet these requirements.
I'm in vehement opposition of any HSSG objectives which has to do with mapping
Ethernet to SONET. Such an effort does not belong in 802.
Note that I don't have any problem whatsoever with the coexistence of Ethernet and
SONET equipment, even in the same box (e.g. router). However, there is no need for
any 802.3 activity to define such coexistence at 10 GbE Ethernet rates. Once the 10
GbE standard is set, many efficient implementations which route 10 GbE to SONET will
spring up.
I've interspersed a few more comments below.
Best Regards,
Rich
--
Bruce_Tolley@xxxxxxxx wrote:
> Rich:
>
> I must both agree and disagree with you.
>
> My own personal leaning is towards the traditional Ethernet approach but the
> HSSG has not really finished defining its goals and no goal decided upon to
> date excludes Paul's proposal.
Paul's proposal specifically excludes most 10 GbE PHY proposals by requiring
specific encoding and delimiter usage to the point of requiring that the Ethernet
PHY = SONET OC-192 PHY. I don't believe that this is in the best interest of 802.3.
If the objectives are as loose as you interpret them, then why the heck did we waste
20 hours of committee time nit picking the HSSG distance objectives???
> >From the very first call for interest there has been discussion of taking
> Ethernet into the WAN.
>
> What has been lacking in the debate is a short concise definition of the
> requirements for Ethernet into the WAN. We might well decide to exclude support
> for SONET for a host of good reasons, but no such decision has yet been made.
>
> We might set for ourselves the goal that not one pint of Yorkshire beer will be
> consumed by any member HSSG until we settle the speed issue!! :-))
>
> Bruce Tolley
> Manager, Business Development
> 3Com Corporation
>
> Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx> on 08/31/99 11:04:39 AM
>
> Please respond to rtaborek@xxxxxxxxxxxxxxxx
>
> Sent by: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
>
> To: HSSG <stds-802-3-hssg@xxxxxxxx>
> cc: (Bruce Tolley/HQ/3Com)
> Subject: Re: Long distance links
>
> Jonathan,
>
> I agree that Paul's statement is concise, but please bear in mind that it has
> NOTHING to do with HSSG work as far as I can tell. I'm not sure if this was
> Paul's intention in his note containing this original text. There are no HSSG
> objectives that even remotely address the issue of "carrying Ethernet frames on
> a SONET system". The closest one is an objective to choose one of two MAC/PLS
> data rates: 10 or 9.584640 Gbps.
>
> I would strongly encourage all proponents of Ethernet over SONET to either
> propose new HSSG objectives addressing these issues, put forth a Call for
> Interest on this issue, or find another forum.
>
> Personally, I don't see any benefit to Ethernet by meeting ANY of Paul's
> requirements and I DO see clear disadvantages with meeting ANY of them. SONET
> transports Ethernet frames just fine today. SONET will be able to transport 10
> GbE frames just fine in the future. Forcing SONET/WAN architectures upon
> Ethernet is not cost effective for either the WAN or LAN environment.
>
> Best Regards,
> Rich
>
> --
>
> Jonathan Thatcher wrote:
>
> > Paul. Thank you!
> >
> > Your words (copied from below) represent the simplest, most concise (perhaps
> > the ONLY concise) set of requirements I remember seeing to date regarding
> > this topic.
> >
> > I would strongly encourage all proponents of Ethernet over SONET to set
> > aside the diatribe and modify, expand upon, or otherwise improve upon this
> > list.
> >
> > -------------- from Paul --------------------------
> > To carry Ethernet frames on a SONET system:
> >
> > 1)Ethernet must match the payload rate of 9.584640 Gbps
> > 2)Ethernet frames must be encoded with NRZ efficiency
> > 3)Ethernet frame delimiting must operate without special symbols
> > ------------ end from Paul ------------------------
> >
> > jonathan
> >
> > > -----Original Message-----
> > > From: pbottorf@xxxxxxxxxxxxxxxxxx [mailto:pbottorf@xxxxxxxxxxxxxxxxxx]
> > > Sent: Monday, August 30, 1999 4:36 PM
> > > To: Rohit Mittal; rtaborek@xxxxxxxxxxxxxxxx
> > > Cc: HSSG
> > > Subject: Re: Long distance links
> > >
> > >
> > >
> > > Rohit:
> > >
> > > At 01:17 PM 8/30/99 -0700, Rohit Mittal wrote:
> > > >
> > > >Rich et al,
> > > >
> > > >One of the things you need to consider is that SONET has
> > > extensive error
> > > monitoring
> > > >"built-in" the overhead to allow speedy detection of
> > > failures before they
> > > degrade
> > > >to serious levels. SONET provides rapid fault isolation.
> > > >
> > > >Now, if you use TCP/IP for the same tasks, you are going to
> > > add latency etc.
> > > >because the frame/data will have to pass through many layers
> > > before any
> > > fault is
> > > >detected. That is the problem in moving up the protocol stack.
> > > >
> > > >For instance, SONET allows less than 50ms time for signal
> > > restoration (due
> > > to cut
> > > >fiber etc.). I do not see anything in Ethernet which can provide
> > > equivalent support
> > > >- maybe Far end fault detector but doesn't that takes a long
> > > time to detect?
> > > >
> > > >IMO, the best solution is just to encapsulate ethernet
> > > frames as data bits
> > > in a
> > > >SONET frame. That way SONET can provide the management features for
> > > preventing
> > > >expensive mantainence and Ethernet can travel as is. Am I overlooking
> > > something?
> > >
> > > To carry Ethernet frames on a SONET system:
> > >
> > > 1)Ethernet must match the payload rate of 9.584640 Gbps
> > > 2)Ethernet frames must be encoded with NRZ efficiency
> > > 3)Ethernet frame delimiting must operate without special symbols
> > >
> > > >
> > > >Rohit Mittal
> > > >Engineering, Microlinear Corp.
> > > >
> > > >> Mark,
> > > >>
> > > >> I believe you're on the right track insofar as digging to
> > > the root of the
> > > >> management issue. The fact of the matter is that Ethernet
> > > does it one
> > > way, and
> > > >> SONET does it another. My sense is the same as yours:
> > > "...instead of
> > > >> transporting management info on dedicated
> > > >> circuits, use TCP/IP and packets. It's the histroric
> > > trend, moving up the
> > > >> protocol stack."
> > > >>
> > > >> I have asked numerous questions over this reflector trying
> > > to get at the
> > > core of
> > > >> requirements for WAN management. I've seen no responses to those
> > > questions. BTW,
> > > >> I'm sill very much interested in hearing the responses to
> > > these questions.
> > > >>
> > > >> Without knowing the requirements for SONET WAN management,
> > > I have to
> > > believe
> > > >> that Ethernet Management, ULP (e.g. Ping, SNMP, Browser) management
> > > mechanisms,
> > > >> Etherenet PHY capabilities for determining things like the
> > > BER of each
> > > link,
> > > >> represent sufficient architecture to implement WAN
> > > management equivalent or
> > > >> superior to that of SONET.
> > > >>
> > > >> Best Regards,
> > > >> Rich
> > > >>
> > > >> --
> > > >>
> > > >> "Gerhold, Mark" wrote:
> > > >>
> > > >> > All,
> > > >> >
> > > >> > It sounds as if one of the biggest issues here is with
> > > the optical
> > > >> > repeaters. If I understand correctly, Sonet repeaters are
> > > instrumented so
> > > >> > that the administrator can isolate problems without
> > > sending out a truck.
> > > >> >
> > > >> > Consider using a 2-port "LAN" switch instead of a
> > > repeater. Switches
> > > today
> > > >> > provide lots of remote maintenance features, including
> > > >> >
> > > >> > o Ping (for I'm alive)
> > > >> > o SNMP (for tons of performance statistics, and alarms)
> > > >> > o Browser management (for ease of use)
> > > >> >
> > > >> > With a switch, instead of transporting management info
> > > on dedicated
> > > >> > circuits, use TCP/IP and packets. It's the histroric
> > > trend, moving up
> > > the
> > > >> > protocol stack.
> > > >> >
> > > >> > Here's a question on a similar vein. Are WDM amplifiers
> > > instrumented to
> > > >> > isolate BER problems? I thought they did optical amplification.
> > > Capturing
> > > >> > BER info sounds tough.
> > > >> >
> > > >> > Thanks,(signing off)
> > > >> >
> > > >> > Mark Gerhold
> > > >> > Unisys
> > > >> >
> > > >> >
> > > >
> > > >
> > > >
> > > 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
-------------------------------------------------------------
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