RE: Long distance links
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
> >