Re: Long distance links
Roy,
I would still like to draw out a complete picture of what is happening and
where. I would love to enable Ethernet over WAN but I think l need your
expertise and education like many people here.
Since Ethernet MAC address is universal, why is there a need to put
additional path information into the Ethernet header? In fact, both Ethernet
and IP address are unique so I suspect that most, if not all of the path
related functions may be derived from them?
Thanks!
Henry Ngai
----- Original Message -----
From: Roy Bynum <rabynum@xxxxxxxxxxx>
To: <rtaborek@xxxxxxxxxxxxxxxx>
Cc: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Monday, August 30, 1999 8:09 PM
Subject: Re: Long distance links
>
> Rich,
>
> You have written that you have studied the functionality of the SONET
protocol.
> 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.
>
> 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.
>
> 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.
>
> 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
>
>