Re: Long distance links
Paul,
I believe that we agree more than you think. You state in the first paragraph of
your note that: "Ethernet is just not viable as a mainstream WAN protocol without
some consideration of SONET." I can't agree more with this statement. What I can't
agree to is either of the following:
1) Rubber stamp the SONET/OC-192 PHY as the 10 GbE PHY; or,
2) Wholesale limitations to the objectives and directions of the HSSG by the
imposition of 9.58464 MAC/PLS rate, NRZ encoding efficiency (I assume you mean 0%
overhead, scrambling, etc. since NRZ by itself doesn't say much), and frame
delimiting without special symbols.
If you're seriously interested in either of the above, I believe you'll encounter
significant hurdles in the HSSG.
If you mean what you say about "some consideration of SONET" then I and many other
HSSG members are eager, ready and willing to listen and learn. I speak from
experience here having participated in the recent and very successful development
of the Gigabit Ethernet architecture. I was one of a group of individuals who
introduced Fibre Channel Physical Layer architecture to the GbE HSSG back in 1996.
FC and GbE folks worked together to take elements of Fibre Channel and fit them
into the Ethernet structure. Careful consideration was given to all aspects of
Ethernet including product implementation, support of the installed base,
migration, operations, performance, etc. The HSSG is ready to "do it again" for 10
GbE.
You yourself during the 10 GbE Call for Interest presented
(http://grouper.ieee.org/groups/802/3/10G_study/public/march99/bottorff_1_0399.pdf)
a "Packets on Photons" architecture (page 5) which essentially shows IP carried by
10 GbE carried by Optics. I see no SONET in this picture. I assume that Optics
stands for DWDM systems. I have no problem with this picture. Is it your intention
is to take the "10 GbE" box and replace it with a SONET/OC192 architecture rubber
stamped by 802.3? If not, what exactly are your intentions?
If the 10 GbE box is filled with an architecture developed by 802.3 to meet the
objectives set forth and agreed to by the HSSG, then I'm perfectly happy to
consider supporting the WAN and considering elements of SONET in achieving this
specific objective.
Best Regards,
Rich
--
Paul Bottorff wrote:
> Rich:
>
> At 02:01 PM 8/31/99 -0700, Rich Taborek wrote:
> >
> >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.
>
> Rich, I think you are completely (and totally) off base. From a market
> share point of view SONET is the WAN. In all the history of Ethernet a
> major factor to success has been the support of the installed base. In the
> early days of Ethernet we adapted Ethernet systems to carry the existing
> protocols for the terminals, hosts, and printers of that day. Though each
> generation of Ethernet we have provided support for existing cabling and
> infrastructure. It is not possible to address the WAN without addressing
> SONET. Ethernet is just not viable as a mainstream WAN protocol without
> some consideration of SONET.
>
> >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.
>
> It is not only normal practice, but the main objective of SONET networks to
> carry other protocols. SONET is not a LAN and does not behave or model like
> an OSI data network. Any analogy between what should be done for an OSI
> data network link and SONET links is misplaced. The best way to think of
> SONET and of DWDM photonic networks is like intelligent wire.
>
> >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.
>
> SONET is not a data protocol. This analogy to Fibre Channel is completely
> mistaken.
> >
> >For the same reason, it is ludicrous to speak about 10 GbE
> transporting/carrying
> >SONET.
>
> Since when are we talking about 10 GigE transporting/carrying SONET? I
> thought we were only talking about SONET transporting/carrying 10 GigE.
>
> >In my mind, it is feasible to expand current HSSG objectives to include
> >the WAN market.
>
> An incredibly small portion of the WAN market could be addressed by
> ignoring the installed base. We are talking about take 10 GigE into the WAN
> mainstream.
>
> >It is NOT prudent nor cost effective for the HSSG to consider
> >carrying Ethernet over SONET.
>
> So why not? Do you have any data to backup these claims? What data makes
> you believe that using the installed base is not prudent or cost effective.
> I'd like to see your market study on the potential and an analysis of where
> these cost are you're talking about.
>
> >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.
>
> I can't believe you want some other forum to design Ethernet.
>
> >
> >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
>
> Cheers,
>
> Paul
>
> >
> >--
> >
> >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
> >
> >
> >
> >
> 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