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