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