Re: Long distance links
Roy Bynum wrote:
> Andy,
...(text deleted)
> There are a several individuals that are both "data" and "telco" that are
> recommending the expansion of 10GbE beyond the traditional LAN only limited
> support functionality. Every "telco" vendor that I have talked to has agreed
> that it is not necessary for 10GbE to implement the entire SONET/SDH OAM&P
> processing functionality in order to carry it over existing SONET/SDH
> technology. A 10GbE standard that leverages the SONET/SDH technology, with
> "path" only processing, will provide for the additional support functionality
> being required by other standards bodies, as well as break the current monopoly
> of MAN/WAN systems and services by the "telco" vendors with their high cost
> interfaces. A 10GbE standard that leverages the SONET/SDH technology will also
> allow the building of 802.3, Native Data, switches that will be able to link
> directly though existing SONET/SDH systems with modifying the 802.3 frame, like
> the existing router and ATM systems do, reducing the cost of the data switch,
> reducing the cost of the ownership of the enterprise and Internet networks, and
> reducing the cost of data services to individual companies and users.
Roy,
For once, I agree with everything you say in the above paragraph, except the first
sentence which should read:
"There are many "data" individuals that are recommending the expansion of 10GbE
beyond the traditional LAN only limited support functionality".
I'd like to know what specifically it will take to accomplish this goal.
Best Regards,
Rich
--
> Thank you,
> Roy Bynum
> MCI WorldCom
>
> 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