Re: Long distance links
Roy Bynum wrote:
> Rich,
>
> You have written that you have studied the functionality of the SONET protocol.
On the contrary, I have now asked for SONET experts to help educate 802.3, especially
myself, on the high-level requirements for WAN transport. I've so far read little else
but banter about what SONET CAN do and what Ethernet CAN'T. I have no bones about
stating that I AM NOT a SONET expert.
> Then you know about the "path" functionality of SONET and SDH. I have written
> several times that I believe that "path" operations support functionality would be
> the minimal needed to support 10GbE over MAN/WAN systems. These functions are "path
> trace", "path label", "path status", and "path bit interleaved parity". Other
> functions that exist in the overhead can be default filled to allow DWDM and
> transmission systems to work with them.
Please define these four new "path" terms and their applicablity in the WAN environment.
I have not seen them defined previously over this reflector. Please also state your
reasons for why you believe their support is required for 10 GbE to support the WAN.
> Brian has written below that the expensive experience of the common carriers does
> not have to be repeated by the Ethernet community. Bill St. Arnaud has written that
> the inband support functionality of GbE using SNMP, Ping, etc. does not give him
> visibility to the support functions of the carrier service systems from his network
> management system. The existing IP network management only sees the fiber plant as
> a black hole. These are anecdotal observations based on the experience of the
> writers.
GbE is not a WAN protocol. Once again, there is no current HSSG objective to support the
WAN. Are you going to propose one? If one is added, the 10 GE effort will address the
objective.
> I have been implementing data networks for 20 years. There are big differences in
> supporting LANs, MANs, WANs, and transport surveillance data communications channel
> (DCC) Q3 networks. As Brian has stated, when you have a LAN with the fiber plant
> easy to get to, and without the need for amplifiers or regenerators, a protocol that
> has no inherent support functionality is easy to support. I have attempted to
> explain some of the problems that are encountered by service providers in supporting
> their fiber networks in previous e-mails.
>
> The primary reason for the need for imbedded support functionality is to save money
> in supporting the implementation of the protocol. It does not add any additional
> capital expense to standardize on a PHY that adds 4% overhead instead of 25%
> overhead. It can save a lot operational expense to standardize on a PHY that adds 4%
> overhead instead of 25% overhead. Having a PHY that adds 4% overhead instead of 25%
> overhead can also speed the implementation of the protocol.
Does your 25% overhead number correcpong to GbE coding overhead? If it does it is
accurate. However, there has been no decision made regarding overhead in 10 GbE. As a
matter of fact, the four early PHY proposals groups range in overhead from a 75% or more
DECREASE in line rate to support 10 Gbps to only one scheme at 25% overhead, with most
schemes operating at a line rate LESS than the data rate. None of the schemes have
proposed a 4% overhead to support what I presume to be SONET fixed management overhead.
Am I correct in assuming that you are mixing line coding overhead and fixed management
overhead in the above paragraph?
Best Regards,
Rich
--
> Thank you,
> Roy Bynum
> MCI WorldCom
>
> Rich Taborek wrote:
>
> > 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
> > >
> > > -----Original Message-----
> > > From: brian.russell@xxxxxxxxxx [mailto:brian.russell@xxxxxxxxxx]
> > > Sent: Monday, August 30, 1999 5:43 AM
> > > To: rtaborek@xxxxxxxxxxxxxxxx; HSSG GbE mail list
> > > Subject: Re: Long distance links
> > >
> > > Hi Rich,
> > >
> > > here are my veiws on the discussion and where I think a few people may not
> > > realise
> > > the break down in costs exist for a system that covers are large area.
> > >
> > > SDH and SONET have used an overhead structure because it saves them money.
> > > Sure
> > > this is at the expense of data, but the leasons learnt from the past in PDH
> > > systems
> > > make this an easy decision.
> > >
> > > From my perspective there is one main difference in what Ethernet has done
> > > in the
> > > past and what it is about to do. That's distance. Ethernet is proposing to
> > > leave
> > > the sanctuary of a building or campus which has full time support staff
> > > ready to
> > > fix any problem when it occurs. As soon as you leave this environment the
> > > cost of
> > > a problem increases exponentially, whether it be during installation,
> > > upgrade or
> > > steady state . This lesson was learnt by the telcos when they first
> > > installed
> > > optical amplifiers over longhaul links. The mantra then was "why waste
> > > bandwidth
> > > with wasteful overhead". The answer was found to be "because men in trucks
> > > going
> > > out to find the problem is expensive!". Take the numerous problems that
> > > arrise
> > > with networks over a working week. Imagine the hassle if the problem is down
> > > the
> > > road somewhere or in another country. Imagine if you are using someone elses
> > > fibre,
> > > you have a high BER and you want to fix it. The system adminisrator will
> > > laugh in
> > > your face if don't have the basic analytical tools at your disposal that
> > > SONET/SDH
> > > gives. This is where the SONET/SDH protocols save money and lots of its.
> > > That's
> > > why they are in business with substantially less people than 15 years ago.
> > > They
> > > have to live with the realisation of JCBs digging up cables, rainwater
> > > shorting out
> > > connections etc. You are not talking about an ideal office situation
> > > anymore.
> > >
> > > Imagine you are trying to place a new optical path through a system running
> > > over
> > > several links around town. If you don't have path tagging (trail trace
> > > identifier
> > > in SDH) in some form this will be a nightmare.
> > >
> > > I beleive one of the reasons why ATM did not take off in the office was
> > > because the
> > > systems people that had to use it already new Ethernet and were not prepared
> > > to
> > > changed to something that looked overly complicated for the job. That
> > > arguement can
> > > hold here in reverse. If you try to use an overly simplistic system to save
> > > a few
> > > dollars and end up with a system that is very expensive to manage and run
> > > then you
> > > will loose. If you use a system that takes on board a system that has
> > > evolved to
> > > give the best cost / benefit ratio for that application you will win.
> > >
> > > Another reason I see for using the SONE/SDH rates is that is will allow
> > > system
> > > manufactures to make cheaper systems that will seamlessly work with Ethernet
> > > and
> > > SONET/SDH at the physical layer. If you choose a different rate then thats
> > > another
> > > chipset , another system test round and thats more money and longer time to
> > > market.
> > > I realise this should not be the primary focus of this forum but systems do
> > > need to
> > > be made and the easier the better.
> > >
> > > regards
> > >
> > > brian
> > >
> > > Brian Russell Ph +353 61 49 5745
> > > Analog Devices Fax +353 61 49 5868
> > > Limerick, Ireland brian.russell@xxxxxxxxxx
> > >
> > > Rich Taborek wrote:
> > >
> > > > Andy,
> > > >
> > > > You're right on target with your assessment. I'll kick off a new thread
> > > with
> > > > this note to address the contentious issue of 10 Gbps Ethernet long
> > > distance
> > > > links. I have tried to steer the discussion on the "Deconstructing OAM&P"
> > > kicked
> > > > off by Hon Wah Chin to focus on determining what, if any, functions of
> > > OAM&P are
> > > > not supported by Ethernet. One strong point of view expressed over this
> > > > reflector is that OAM&P is the ONLY way to support long links and that the
> > > rest
> > > > of SONET/SDH is intimately tied in with OAM&P and, therefore, REQUIRED to
> > > > support long links. I'd like to point out an old saying: "There's more
> > > than one
> > > > way to skin a cat". It's crude, but appropriate.
> > > >
> > > > It is important to note that that current HSSG objectives call for support
> > > of
> > > > Ethernet links at distances of up to 40 km. The only media I'm aware of
> > > that can
> > > > achieve these distances in a single Ethernet link (i.e. without
> > > intermediate
> > > > EDFAs, regens, etc.) is singlemode fiber. I'm further assuming that the
> > > fiber
> > > > can be leased, owned, begged, borrowed or stolen as this parameter will
> > > NOT be
> > > > part of the eventual 10 Gbps Ethernet standard. Beyond this objective,
> > > there are
> > > > no related objectives nor sub-objectives to support ANY components of
> > > SONET/SDH
> > > > and/or OAM&P. Any such objectives or sub-objectives must be clearly and
> > > > concisely defined and presented to the HSSG and then voted upon by HSSG
> > > members,
> > > > attaining 75% approval in order to be considered a formal objective.
> > > >
> > > > 802.3 and the HSSG is not a telco standards forum. I'd like to make it
> > > clear
> > > > that the resoponsibility is on proponents of telco-style long distance
> > > links to
> > > > educate the 802.3 committee on aspects of SONET/SDH and OAM&P which are
> > > lacking
> > > > in Etherent and are absolutely required to meet HSSG objectives. What the
> > > 802.3
> > > > committee is very good at is architecting copper and fiber-optic based
> > > links
> > > > capable of reliably and cost effectively transporting data at distances of
> > > up to
> > > > 10s of km. In this respect, Ethernet has no match. Current HSSG objectives
> > > will
> > > > position Ethernet to go much faster and farther than the current Ethernet
> > > > standard.
> > > >
> > > > Ethernet operates significantly differently than does SONET/SDH and OAM&P.
> > > Any
> > > > discussion which points out differences between Ethernet and
> > > SONET/SDH/OAM&P is
> > > > essentially irrelevant to the work of the HSSG unless the differences
> > > cannot be
> > > > effecively acoomodated in 802.3 or elsewhere in the 802 protocol stack.
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > Andy Leigh wrote:
> > > >
> > > > > One of the things that is not be accounted for is that much of
> > > SDH/SONET's
> > > > > OAM&P information is carried as serial bits inside the transport
> > > overhead
> > > > > bytes. These bytes are either in use by OAM&P or are "silent". Not
> > > running
> > > > > SDH/SONET OAM&P doesn't get you back any bandwidth. It's also completely
> > > > > independent of the stream being transported. If a OC192 links is 100%
> > > > > congested carrying Ethernet frames, the OAM&P functions will still
> > > operate
> > > > > perfectly. Although accounted for in the bandwidth, this stuff is really
> > > > > "out of band" as far as the payload is concerned.
> > > > >
> > > > > Now, I think all of this is largely irrelevant. As far as I can see,
> > > what's
> > > > > being debated here is using SDH/SONET engineering to achieve long
> > > distances.
> > > > > What we're really describing is the use of SDH/SONET "repeaters" because
> > > > > these already exist. If, instead we intend 10GBE to run as a service
> > > over a
> > > > > telco's OC192 infrastructure, then just translate (L2 bridge) at the
> > > ends
> > > > > and let the Telco use SDH/SONET management tools to run their
> > > > > infrastructure, If on the other hand, we want to "pinch" chipsets and
> > > > > hardware to make 10GBE go the distance without re-inventing the wheel,
> > > then
> > > > > don't bother implementing SDH/SONET's bells and whistles...
> > > > >
> > > > > This is really not an Ethernet issue, but a Telco standards issue. I'd
> > > avoid
> > > > > it like the plague.
> > > > >
> > > > > Andy Leigh
> > > > > Senior Planning Engineer, Strategic Network Developments, New Technology
> > > > > Tel: +44 (0)171 765 0575
> > > > > Fax: +44 (0)171 765 0557
> > > > > Pager: 01893 323488
---------------------------------------------------------------
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