RE: Deconstructing OAM&P
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
>