Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: OAM&P mapping


Not at all. The Ethernet OAM&P transport is completely deterministic in terms of
the minimum throughput of OAM&P information. I also believe that the throughput
exceeds that of SONET OAM&P so this should not be an issue. 

Jumbo frames are not supported by IEEE 802.3. This is also not an issue.
Notwithstanding, I believe that the minimum throughput of the proposed Ethernet
OAM&P transport exceeds that of SONET OAM&P even if jumbo frames are used.

To summarize, the proposed Ethernet OAM&P transport is as "deterministic" as
a SONET OAM&P transport. Synchronous, it isn't. Deterministic, it is.

Best Regards,

Roy Bynum wrote:
> Rich,
> All issues of coding aside, from what you are saying, if I understand you,
> the OM (operations and maintenance) functions that you would use within the
> IPG would be non-deterministic in the amount of information that could be
> transferred.  I express this in that the IPG only occurs between valid data
> frames, which could be of any size.  It means that the higher percentage of
> larger and/or (heresy) jumbo frame, the less information can be transferred
> by the IPG.
> This may not necessarily be all bad issue, but it is one that should be
> examined in consideration that the WAN compatible PHY has a deterministic
> minimum of information to be transferred.  It also has ramifications for the
> use of  jumbo frames, should 802.3, in the future, decide to make provision
> for them.  While it is not part of the standard, several of the Ethernet
> vendors provide support for jumbo frames in their current products.
> As part of the definition on the receive side of the interface, the idle
> time that occurs during the sync frame could be used to transfer the
> information from the previous sync frame.  This would make the information
> out of sync or non-current by at least 125us.  The hold, or idle time for
> the transmitting side could also be used for information transfer.
> The use of sync frame idle time could provide for the deterministic amount
> of information that would originate in the WAN compatible PHY.  The
> deterministic nature of the WAN compatible PHY would then also provide some
> advantage for OM functions in support of jumbo frames when they become more
> common or in the advent that they are standardized.
> I am not sure how the others that are working on versions of the WAN
> compatible PHY would think about this.  What do you think?
> Regards,
> Roy Bynum
> -- 
> >
> > Roy Bynum wrote:
> > >
> > > Rich, the way that WAN compatible systems provide for maintenance and
> > > performance information is radically different from FC.  FC uses control
> > > codes imbedded in the encoded binary signal stream, in band with the
> > > data.
> > >
> > > The operational and performance intelligence is at the MAC, not the PHY.
> > > The WAN compatible systems use out dedicated bytes located in the out of
> > > band synchronization frames.  The out of band functionality is so that
> > > customer's can get service level agreements from service providers
> > > without having to give the service provider access to their data stream.
> > > (In this day and age of security and privicy issues, I am sure that you
> > > can understand this.)
> >
> > Roy,
> >
> > This is a non issue. Any information contained in the IPG of an Ethernet
> > packet stream is analogous to overhead bytes in a SONET/SDH frame. Neither
> > can be considered to be, nor affect customer data, security, privacy, SLAs
> > in any way.
> >
> > The Ethernet OAM&P transport proposal from Mr. Osamu Ishida and myself use
> > the Ethernet PHY only, and do not involve the MAC in any fashion. OAM&P
> > information terminated in the Reconciliation sublayer which is considered
> > to be part of the PHY, not Data Link Layer, which includes the MAC. This
> > information is sourced/routed to PHY Station Management.
> >
> > > Somehow, in order to be PHY independant, something other than the use of
> > > FC control words must be agreed on.  Otherwise, the MAC/PHY relationship
> > > will continue to polorize between the "LAN only PHY" with block encoding
> > > and the "WAN compatible PHY" with scramble encoding. I do not consider
> > > the proposed "UniPHY" as anything but noise because of an apparent lack
> > > of understanding of the differences between the OAM&P functions of the
> > > different PHYs.
> >
> > You're sinking again :-)
> >
> > The Ethernet OAM&P proposal being assembled here meets all HSSG objectives
> > and seamlessly fits into strongly endorsed proposals to support LAN and
> > WAN applications.
Richard Taborek Sr.                 Phone: 408-845-6102       
Chief Technology Officer             Cell: 408-832-3957
nSerial Corporation                   Fax: 408-845-6114
2500-5 Augustine Dr.        mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054