RE: Deconstructing OAM&P
Roy,
please excuse me playing devil's advocate..
> With exception of a few GbE switch vendor support engineers, and perhaps
Bill
> St. Arnaud, most "data" people have little or no experience with
implementing
> 802.3 natively over WDM, DWDM, leased fiber, or any other distance outside
of a
> building. Experience with carrying data over WDM, DWDM, leased fiber, or
any
> other distance outside of a building is largely with "telco" people. As I
work
> for a "telco" service provider, even though I have 30 years of data
experience,
> I am considered a "telco" as well as a "data" person. There are a few
others in
> the group that are both "data" and "telco".
I work in a small team that do data, telco & broadcast - convergence anyone?
However, I do mostly data.
> In order for 802.3 to reliably be used over WDM, DWDM, leased fiber, or
any
> other distance outside the building, it needs more operations and
maintenance
> support than it currently has. Many "data" only people believe that they
can
> get away with the traditional LAN only limited support functionality.
Well, Ethernet_II in and of itself has no O & M built in (nearly 100% of
Ethernet traffic is not 802.3/802.2). Devices can keep stats, and these are
collected in SNMP-type MIBs (and IP standard). Command and Control is mostly
exercised in-band using SNMP over IP over Ethernet to manage switches etc.
With the abandonment of CSMA/CD, Ethernet finds itself more and more just a
standard frame format...
> Every non-IEEE standards body is looking at standards that will overlay
802.3
> with additional support functionality that will greatly increase the cost
of Native
> 802.3 over these systems, if it will be used at all. It will also
maintain the
> monopoly of MAN/WAN systems and services as the "telco" domain.
Where maybe it should remain? With so many seats of Ethernet around, adding
extra functionality that doesn't make life easier/quicker/more flexible for
end-users will not see huge take-up
> 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.
Why not just translate at the edge and use OAM&P where it can be used
> 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.
So, by spreading the cost of hugely complicated interfaces of millions of
seats that don't need the functionality, we drive the cost down. From where
I stand, I want a cheap/fast pipe for gluing together my cheap fast boxes. I
expect WAN connections to be expensive because I probably use only one WAN
connection for every 200 LAN connections
> 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.
But that isn't what I need first and foremost. I want to be able to build
clusters of switches with high-speed backbones in such a way that the
inter-switch link is not a bottle-neck. The money that expensive interfaces
cost is just a fraction of the money we pay to Telcos.
Andy
> 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
> > >