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