Re: Long distance links
Jonathan,
I don't think we're communicating. I may be completely off base, but it seems to
me that you're confusing SONET with the WAN. Ethernet includes MAC and PHY
layers as its primary OSI layers. SONET does the same. Carrying one MAC and PHY
layer over another is not normal practice nor recommended. Please allow me to
make the following analogy:
For example, the SAN market today is being driven by Fibre Channel. Fibre
Channel is essentially equivalent to Ethernet in that the MAC and PHY layers are
supported. To provide SAN support, Fibre Channel transports (carries) the
SCSI-3 Command Set. Fibre Channel DOES NOT transport the SCSI Physical Layer.
Doing so would be ludicrous except to satisfy the migration requirements of
legacy products.
For the same reason, it is ludicrous to speak about 10 GbE transporting/carrying
SONET. In my mind, it is feasible to expand current HSSG objectives to include
the WAN market. It is NOT prudent nor cost effective for the HSSG to consider
carrying Ethernet over SONET. IEEE 802 is not the proper forum in which to
address such an effort even if it deemed worthy to address. My suggestion to you
is to call any discussion of carrying Ethernet over SONET out of order.
P.S. I have no objections and would STRONGLY support an HSSG objective to have
Ethernet support the WAN environment. My current view is that Ethernet is king
in the LAN and that the MAN is the "DMZ" between the LAN and WAN.
Best Regards,
Rich
--
Jonathan Thatcher wrote:
> Rich,
>
> It is certainly true that our current objectives do not support developing a
> standard supporting Ethernet over SONET. Neither is there an anti-objective
> directing us to not look at support of Ethernet over SONET. Had the later
> been true, I would have called all discussion out-of-order (like was done
> with jumbo frames).
>
> As you suggest, the basis for the discussion is to resolve the issue of
> 10.0000 vs 9.58464 Gb/s. If germane to this decision is a decision on
> whether or not to support Ethernet over SONET, then let us make it. To make
> that decision, we must understand the pro's and con's. As best as I can tell
> the pro is simple: we can directly ship packets over the WAN infrastructure.
> The con's are those things that complicate Ethernet; things that require
> changes to Ethernet; things that add cost to Ethernet.
>
> My interest in a clear, concise list of requirements is that it will focus
> the discussion, provide a less ambiguous backdrop for making decisions, and
> allow the group to progress more rapidly. The process is one we have all
> used many times: 1. write down the list of requirements; 2. prioritize the
> list; 3. identify alternatives; 4. evaluate the cost/benefit; 5. make a
> decision; 6. execute. 7. Iterate as necessary, research as necessary.
>
> The onus of the first step is on the proponents of the idea.
>
> jonathan
>
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
> > Sent: Tuesday, August 31, 1999 12:05 PM
> > To: HSSG
> > 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