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