Re: OAM&P mapping
Rich,
Just a comment below in the way of an explanation.
Best regards,
Roy
----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Sunday, April 09, 2000 4:43 AM
Subject: 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.
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.)
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
>
> > 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?
>
> > 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?
>
> > 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?
>
> > 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.
Rich, this would be equivelent to a positive as well as negative condition
similar to, and related to, "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
>
>