OAM&P mapping
Roy,
I'm going to take the liberty to rename this thread to "OAM&P mapping" because I
feel you have some excellent contributions to that topic which would surely get
lost in the thread you used in your original note.
I'd be honored to work with others including Mr. Osamu Ishida to present
complete details for supporting Ethernet OAM&P transport which is PCS, interface
and LAN/WAN independent during the May interim meeting in Ottawa.
I have a few more comments below.
Best Regards,
Rich
--
Roy Bynum wrote:
>
> Rich,
>
> I think that it is over due to discuss the what the operational and
> maintenance requirements are for both the LAN only PHY and the WAN
> compatible PHY. As far as I know, those requirements have not been
> discussed.
I agree. My sense is that the maintenance requirements are independent of the
PHY type and are more application dependent. I envision maintenance requirements
for the LAN to be a small subset of those for the MAN/WAN. I assume that most of
the guidance for Ethernet MAN/WAN maintenance requirements will come from
SONET/SDH OAM&P.
> Even if the two PHY would have different requirements, both PHYs need to
> communicate through a maintenance function. The nature of that maintenance
> function has yet to be defined for either PHY.
Ethernet already defines Station Management and a management interface,
protocol, registers, etc. What I have proposed so far is merely the transport of
management information from station-to-station.
> Perhaps this is part of the source of some the confusion around the RS/PCS
> interface and XAUI. Many of us could see no reason for why you were taking
> it for granted that certain 8B10B control codes would be used, when there
> was no specific requirement for their use.
Once again, I don't understand why 8B/10B keeps coming up. SONET/SDH uses
overhead bytes to transport OAM&P. Control codes embedded within an Ethernet IPG
can perform the same function.
> 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
> 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
> 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.
> Local Section BIP/Second (from PHY to MAC) - reports the bit error rate of
> signal into the local interface for the directly connected fiber facilities
> Remote Section BIP/Second (from PHY to MAC) - reports the bit error rate of
> the signal into the remote interface of the directly connected fiber
> facilities
Ditto
> Local Path Trace (16 octet alpha) (from MAC to PHY) - writes a user defined
> path identifier into the path trace byte for identification of the local
> interface to the remote end
> Remote Path Trace (16 octet alpha) (from PHY to MAC) - reports the user
> defined path identifier from the path trace byte to identify the interface
> at the remote end
This sounds like stuff from the XGENIE proposal and easily supported under that
proposal.
> I think that these are the functions that reflect the active bytes proposed
> in the sync overhead of the WAN compatible PHY. In addition, there may be
> some functions that are at the MAC interface that need to be communicated
> such as:
>
> 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.
> Perhaps with this information we can start a meaningful dialog about what
> and why any error codes or other indicators and what the technical details
> of the maintenance functions would be for the different PHYs.
>
> Thank you,
> Roy Bynum
>
> --
>
> Roy,
>
> Break Link and Remote Fault are Ethernet constructs supported in Fast
> Ethernet at well as Gigabit Ethernet.
>
> For full-duplex links (i.e. all Gigabit and above Ethernet links as well as
> many at lower speeds) it becomes increasingly important to completely remove
> a link from operation when one direction is broken. Since there is no
> handshaking proposed for 10 GbE protocol, even during initialization, and no
> Auto-Negotiation is proposed, BL and RF control-codes are a great choice
> for the implementation of these important Ethernet functions.
>
> For further information on these functions and their specification, please
> see standard IEEE 802.3.
>
> Best Regards,
> Rich
>
> > > Roy Bynum wrote:
> > > >
> > > > Rich,
> > > >
> > > > Part of your specifications and the discussion resulting from your
> > diagrams
> > > > is that the AN functions that were in GbE would also be duplicated in
> > 10GbE.
> > > > You include "/RF/" and "/BL/" control codes as part the assumptions of
> > your
> > > > reference diagram. You are again taking for granted something that
> you
> > > > acknowledge was not accepted by the HSSG. This type of "assumed"
> > > > functionality is adding to the confusion of a lot of people. The
> issue
> > of
> > > > control codes, AN, etc.can be brought up again specifically as part of
> > the
> > > > LAN only PHY at the next meeting. In the mean time, other control
> codes
> > > > have not been defined as yet originating from the MAC for P802.3ae.
> At
> > > > present, only "normal interframe"(/i/), "valid data" (/d/), and
> > "error"(/e/)
> > > > can be assumed as the requirements for the RS.
> > > >
> > > > Thank you,
> > > > Roy Bynum
-------------------------------------------------------
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