Re: Long distance links
Mick,
You beat me to the punch with your response to Brian Russell's note. I agree
with your response 100%.
Bottom line is that Ethernet and higher layer management gathering, transport,
delivery, etc. facilities are more than capable of extending into the WAN. I'd
like to hear specific arguments to the contrary.
Given the assertion above, there is no clear reason to have 10 GbE operate at
SONET/SDH rates for management reasons or otherwise, when virtually ALL the
equipment generating and sinking the data traffic is Ethernet based.
Best Regards,
Rich
--
Mick Seaman wrote:
> Brian,
> You appear to making the assumption that the functionality that you need
> cannot be realized above, as opposed to embedded within, the Gigabit MAC.
> This therefore appears to be a discussion about repeaters since a direct
> switch to switch link can just as well be managed by protocol exchanged on
> top of the link.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of
> brian.russell@xxxxxxxxxx
> Sent: Monday, August 30, 1999 4: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
> > >
> > > > -----Original Message-----
> > > > From: Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxxxxx]
> > > > Sent: Wednesday, August 25, 1999 1:03 AM
> > > > To: rabynum@xxxxxxxxxxx; HSSG
> > > > Subject: Re: Deconstructing OAM&P
> > > >
> > > >
> > > > Roy Bynum wrote:
> > > >
> > > > > Rich,
> > > > >
> > > > > I believe that we are agreeing that the only level of operations and
> > > > performance information
> > > > > that is needed to be leveraged from the SONET/SDH system is the
> "Path".
> > > >
> > > > Roy,
> > > >
> > > > Given that a SONET/SDH "Path" = Ethernet "Link" according to your
> prior
> > > > note, I believe that we
> > > > agree that Ethernet already supports the gathering and transport of
> > > > information required to
> > > > maintain a link. I'm not sure what exactly you mean by "operations and
> > > > performance information",
> > > > but I believe that existing Ethernet structures can be used to gather
> and
> > > > transport such
> > > > information.
> > > >
> > > > > You do not want to use inband traffic bandwidth to send and receive
> > > > physical layer operations and
> > > > > maintenance
> > > > > information.
> > > >
> > > > On the contrary, in Ethernet you do. The point I made in my previous
> note
> > > > (copied below) is that
> > > > Ethernet transports maintenance information in a different manner than
> > > > does SONET. I believe that
> > > > at 10 Gbps, the Ethernet methodology is capable of transporting
> > > > maintenance information with
> > > > greater efficiency than does SONET. This is due to the low frequency
> > > > transport requirements of
> > > > maintenance information.
> > > >
> > > > > All of these things would not be as available without leveraging
> the
> > > > SONET/SDH
> > > > > technology. Otherwise a lot of time will be spent developing new
> > > > technology might delay the
> > > > > deployment of 10GbE and the additional development money will have
> to
> > > > recovered in a higher
> > > > > cost interface.
> > > >
> > > > What new technology? Little or no time need be spent on 10 GbE
> maintenance
> > > > and transport since the
> > > > required structures are already in place. The key question posed by
> Hon
> > > > Wah Chin in a previous note
> > > > was one inquiring about the requirements of the "M" or Maintenance
> > > > component of OAM&P? As a
> > > > high-level requirements set, what is supported by the SONET/SDH
> > > > Maintenance component which is not
> > > > directly supportable via existing Ethernet management gathering or
> > > > transport structures?
> > > >
> > > > > Since 10GbE is going to be full duplex, the fiber or wavelength
> that
> > > > will
> > > > > transmitting, will not be same as the one that is receiving. There
> will
> > > > be two separate "links"
> > > > > between any two interface ports.
> > > >
> > > > Absolutely. The full duplex nature of Ethernet greatly simplifies many
> > > > aspects of link management.
> > > > Do you view the required full duplex nature of Ethernet as a
> disadvantage
> > > > with respect to
> > > > management?
> > > >
> > > > > Thank you,
> > > > > Roy Bynum
> > > > > MCI WorldCom
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > > Rich Taborek wrote:
> > > > >
> > > > > > Roy Bynum wrote:
> > > > > >
> > > > > > > Rich,
> > > > > > >
> > > > > > > You are correct. A full duplex Ethernet link is equivalent to
> the
> > > > "Path" of a
> > > > > > > SONET/SDH system. I believe that the new term that is being
> used in
> > > > the OIF is
> > > > > > > "Trail".
> > > > > > >
> > > > > > > The "Line" definition within SONET/SDH are equivalent to the WAN
> > > > service link. This
> > > > > > > would apply to situations where 10GbE would be put on active
> DWDM
> > > > systems or commercial
> > > > > > > SONET/SDH services. The active "Line" information processing
> would
> > > > be done on the
> > > > > > > active DWDM or the SONET/SDH systems, not the 10GbE port or
> switch.
> > > > The "Section"
> > > > > > > function of SONET/SDH deals with physical fiber connections
> between
> > > > DWDM or SONET/SDH
> > > > > > > Line Terminating Equipment or regenerators. Again, this would
> not
> > > > be part of the 10GbE
> > > > > > > port or switch processing.
> > > > > >
> > > > > > This sounds appropriate. Is a fair comparison that a "Line" is
> > > > equivalent to a SONET/SDH
> > > > > > transport which could encapsulate the payload of 10 Gbps Ethernet
> > > > packets? Is the equipment
> > > > > > that commonly converts from one to the other commonly referred to
> as a
> > > > bridge or router? If
> > > > > > it is, then this discussion is not relevant to the objectives of
> the
> > > > HSSG. The HSSG is
> > > > > > focused on developing 10 Gbps Ethernet optical links to meet
> distance
> > > > requirements of up to
> > > > > > 40 km.
> > > > > >
> > > > > > > Within the SONET/SDH path OAM functionality are several items
> that
> > > > would be useful.
> > > > > > > There is a path origination identification that is equivalent to
> the
> > > > port MAC address
> > > > > > > of an Ethernet port. This allows service providers to identify
> the
> > > > customer link
> > > > > > > without looking at any of the data. It will also allow MAC to
> MAC
> > > > link identification
> > > > > > > without impacting any of the active traffic. There is a bit
> > > > interleave parity function
> > > > > > > that can be used to detect bit errors that also does not impact
> > > > active traffic. There
> > > > > > > is a status indicator that can send some status and link
> received
> > > > error performance
> > > > > > > information back to the far end port, again without impacting
> the
> > > > active traffic.
> > > > > > > There are other items that might also be used. I will be going
> over
> > > > these at the Kent
> > > > > > > meeting.
> > > > > >
> > > > > > In native Ethernet, there is no need to burden the Physical layer
> with
> > > > overhead
> > > > > > specifically allocated to configuration or link maintenance and
> its
> > > > corresponding
> > > > > > management. In general, packet-based LANs and SAN, including
> Ethernet,
> > > > meet configuration,
> > > > > > link maintenance and general management requirements by
> architecting
> > > > measurement facilities
> > > > > > at the Physical layer and Transport facilities at the MAC layer
> and
> > > > above. The reasoning
> > > > > > being that since optical links typically operate at link BER rates
> > > > much lower than 10^-12,
> > > > > > and that configuration and other management requests are very
> > > > infrequent. Therefore, a more
> > > > > > efficient use of link bandwidth is to send management packets on
> an
> > > > as-needed rather than
> > > > > > synchronous basis. This to me "impacts the active traffic" much
> less
> > > > than does a
> > > > > > synchronous management transport alternative.
> > > > > >
> > > > > > Please also note the protocol danger of reporting management (e.g.
> > > > error) information using
> > > > > > the same link which recognized the error, and of using the same
> and
> > > > loop/ring protocol to
> > > > > > do so. Much confusion can result, akin to playing the game of
> > > > "telephone", with a group of
> > > > > > folks arranged in a circle whispering in each others ear. The
> original
> > > > transmitter of the
> > > > > > message will typically and eventually receive a corrupted copy of
> the
> > > > original message.
> > > > > > This problem is solved by employing switched architectures and
> higher
> > > > level-based protocol
> > > > > > transports.
> > > >
-------------------------------------------------------------
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