Re: OAM&P mapping
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
----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Sunday, April 09, 2000 2:22 PM
Subject: Re: OAM&P mapping
>
> 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.
>
> > > > I will let you state what you believe the operational and
maintenance
> > > > requirements should be for the LAN only PHY. From what I have seen,
the
> > > > WAN compatible PHY will have slightly greater requirements than the
LAN
> > > > only PHY.
> > >
> > > You've done a great job below already. I also know that Mr. Osamu
Ishida
> > > is working on a similar list of Ethernet OAM&P requirements and
functions.
> > >
> > > > I believe that the WAN compatible PHY should have the following
> > > > information exchange between the PHY and the MAC:
> > > >
> > > > Local Optical Link Up/Down (from PHY to MAC) - reports condition of
> > > > optical signal into the local interface
> > > > Remote Optical Link Up/Down (from PHY to MAC) - reports condition of
> > > > optical signal into the remote interface
> > >
> > > Already there for Ethernet
> >
> > Rich, what flavor of "Ethenet" are your referring to?
>
> At least 1000BASE-X. I'm not all that familiar with lower speed optical
Ethernet
> variants based on FDDI. However, all Ethernet links support the concept of
Link
> Status.
>
> > > > Local link Sync Valid/Invalid (from PHY to MAC) - reports condition
of
> > > > signal sync into the local interface
> > > > Remote link Sync Valid/Invalid (from PHY to MAC) - reports condition
of
> > > > signal sync into the remote interface
> > >
> > > Already there for Ethernet
> >
> > Rich, what flavor of "Ethenet" are your referring to?
>
> I believe all flavors. As an example, 1000BASE-X, which will likely be
most
> similar to 10 GbE reports sync_status within the PHY. These and other
signals
> and conditions are finally reported as Link Status.
>
> > > > Local Path BIP/Second (from PHY to MAC) - reports the bit error rate
of
> > > > signal into the local interface for the end to end path
> > > > Remote Path BIP/Second (from PHY to MAC) - reports the bit error
rate of
> > > > signal into the remote interface for the end to end path
> > >
> > > BER determination and reporting is supported by the current LAN and
> > > Uni-PHY proposals.
> >
> > Rich, could you point me to where that is defined for the out of band
bytes
> > in the LAN and "UniPHY" presentations so far?
>
> Check various reflector notes for discussions on BER determination and
reporting
> for 8B/10B and 64B/66B transmission code. Overhead bytes are defined in
> SONET/SDH to support both BER determination and reporting. No additional
> overhead is required by the Ethernet OAM&P proposal for BER determination
and
> reporting. I'll work on the details for the May Interim meeting.
>
> > > > Remote Data Link Valid/Invalid - (from remote MAC to local MAC
through
> > > > remote path error indicator) - reports condition of data link
between
> > > > interfaces at the end to end path level
> > >
> > > This sound like the opposite of Remote Fault.
> >
> > Rich, this would be equivelent to a positive as well as negative
condition
> > similar to, and related to, "Remote Fault".
>
> I'm having trouble parsing this statement. Either my incoming path is
working or
> it's not. If it's working, only path quality need be reported. If it's
broke, I
> need to report this condition to the initiating end. Please explain if I
am
> completely misinterpreting this requirement.
>
> > Best regards,
> > Roy
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------
> 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