Re: OAM&P mapping
Roy,
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,
Rich
--
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 http://www.nSerial.com