Re: AW: Deconstructing OAM&P
Roy,
You should inquire with companies that have 802.3 networks as to whether or
not they can manage them. Lots of vendors have sold lots of network
management hardware and software to these companies. It may not be what
you prefer, but it is misleading to infer that it doesn't exist!!!
At 08:30 PM 8/25/99 -0500, you wrote:
>Walt,
>
>If you could turn back time, and do away with full duplex optical 802.3, you
>might could prevent the expansion of 802.3 into the WAN environment.
>Unfortunately, time can not be erased, or the previous work done by the
>802.3 WG. 802.3 is already being implemented over WAN services. The only
>problem is that it can not manage itself. I would much rather see the HSSG
>control the standard than allow other standards organizations that have
>other agenda's take control it.
>
>Thank you,
>Roy Bynum
>MCI WorldCom
>
>
>
>
>Walter Thirion wrote:
>
> > This statement is exactly what many people are afraid of and what we
> > tried desperately to separate in the speed ad hoc. Asking 802.3 to buy
> > into the WAN management protocol is going to be very difficult. It is
> > similar to the problem we've been having trying to separate the line
> > code from the MAC/PLS speed.
> >
> > Walt
> >
> > > -----Original Message-----
> > > From: Roy Bynum [mailto:rabynum@xxxxxxxxxxx]
> > > Sent: Wednesday, August 25, 1999 8:17 AM
> > > To: rtaborek@xxxxxxxxxxxxxxxx
> > > Cc: Heiles Juergen; HSSG
> > > Subject: Re: AW: Deconstructing OAM&P
> > >
> > >
> > >
> > > Rich,
> > >
> > > I do not think that an OC rate MAC/PHY would have been
> > > suggested by several
> > > different people if it were not for the OAM&P issue.
> > >
> > > Thank you,
> > > Roy Bynum
> > > MCI WorldCom
> > >
> > > Rich Taborek wrote:
> > >
> > > > Juergen,
> > > >
> > > > I believe that the OAM&P discussion is separate from the
> > > speed discussion. For
> > > > example, regardless of whether the HSSG votes in either 10
> > > Gbps or 9.58464 Gbps
> > > > as a speed objective, several folks, primarily Hon Wah Chin
> > > or Optical Networks,
> > > > has suggested that we carefully look at each of the
> > > elements of OAM&P for
> > > > possible consideration as additional HSSG objectives.
> > > >
> > > > It is not appropriate for the HSSG to address any issue
> > > related to existing
> > > > SONET OC-192 and its associted OAM&P specs.
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > Heiles Juergen wrote:
> > > >
> > > > > I am following the OAM&P discussion only for a short time
> > > and have a
> > > > > question for clarification.
> > > > >
> > > > > Currently two data rates for 10GbE are under discussion
> > > 10 Gbit/s and
> > > > > 9.58464 Gbit/s. As far as I understand, 9.58464 Gbit/s is
> > > proposed as it
> > > > > would allow mapping of 10 GbE into a SONET STS-192c SPE.
> > > In this case SONET
> > > > > could provide all the required OAM&P functions via its
> > > section, line and
> > > > > path overhead. The STS-192c SPE would be the end-to-end
> > > path discussed
> > > > > below.
> > > > > So I assume that the OAM&P discussion is related to the
> > > case the 10 GbE is
> > > > > not transported via SONET or similary transport
> > > techniques which provide the
> > > > > same OAM&P functionality (e.g. Digital Wrapper for the OTN).
> > > > > Is this assumption correct?
> > > > >
> > > > > Juergen Heiles
> > > > > Siemens AG
> > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Roy Bynum [SMTP:rabynum@xxxxxxxxxxx]
> > > > > > Gesendet am: Dienstag, 24. August 1999 07:58
> > > > > > An: rtaborek@xxxxxxxxxxxxxxxx
> > > > > > Cc: HSSG
> > > > > > Betreff: Re: Deconstructing OAM&P
> > > > > >
> > > > > >
> > > > > > 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".
> > > > > > You do not want to use
> > > > > > inband traffic bandwidth to send and receive physical
> > > layer operations and
> > > > > > 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. 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.
> > > > > >
> > > > > > Thank you,
> > > > > > Roy Bynum
> > > > > > MCI WorldCom
> > > > > >
> > > > > > 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
> > >
Fred Weniger
Gigabit Product Marketing Manager
805-388-7571
weniger@xxxxxxxxxxx