Re: Interface reality check
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.
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.
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.
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.
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
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
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
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
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
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
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
----- Original Message -----
From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: Saturday, April 08, 2000 2:17 AM
Subject: Re: Interface reality check
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
> > >
> > > --
> > >
> > > > Roy,
> > > >
> > > > I am fully aware that not only is Auto-Negotiation not included in
> > > > P802.3ae objectives, that a motion I made proposing AN for 10 GbE
> > > > in September, 1999 failed miserably. As usual, I get over my failed
> > > > motions rather quickly.
> > > >
> > > > If you have an issue with AN, please bring it up. From my
perspective,
> it
> > > > has no bearing on this thread.
> > > >
> > > > Non support of AN in 10 GbE has no bearing on the independent
> requirements
> > > > to support Remote Fault and/or Break Link functionality in 10 GbE.
> That
> > > > was the thread being discussed.
> > > >
> > > > BTW: is support of these functions being considered by proponents of
a
> > > > pure scrambled code over all proposed 10 GbE interfaces and
sublayers
> > > > and for all proposed PHY variants?
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > Roy Bynum wrote:
> > > > >
> > > > > Rich,
> > > > >
> > > > > If you will re-examine the objectives, you will discover that
> > > > > Auto-Negotiation is not supported by P802.3ae.
> > > > >
> > > > > Thank you,
> > > > > Roy Bynum
> > > > >
> > > > > --
> > > > > >
> > > > > > Roy,
> > > > > >
> > > > > > In GbE, Remote Fault and Break Link are both signaled during
> > > > > > Auto-Negotiation (AN). For 1000BASE-X GbE, AN is a management
> > > > > > function that executes mutually exclusively with normal PCS
> > > > > > functions. AN is specified in 1000BASE-X clause 37 while the
> > > > > > PCS is specified in clause 36. GbE AN control input is from
> > > > > > management, not the RS. GbE AN functions "take over" the GbE PCS
> for
> > > > > > use as an AN transport. The GbE MAC, RS, management, AN and PCS
> > > > > > functions are typically integrated.
> > > > > >
> > > > > > My RS proposal simply has the RS receiver treating all control
> codes
> > > > > > not specified by 802.3ae to have special meaning as Idle. This
> rule
> > > > > > would apply to every RS receiver.
> > > > > >
> > > > > > Best Regards,
> > > > > > Rich
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Roy Bynum wrote:
> > > > > > >
> > > > > > > Rich,
> > > > > > >
> > > > > > > Please explain. The "remote fault" and "break link"
indicators
> that
> > > are
> > > > > > > in GbE, are these transmitted from the RS to the PCS as part
of
> the
> > > RS
> > > > > > > information, or are these transmitted from the PCS to the RS
> during
> > > the
> > > > > > > "non-data" periods of received data?
> > > > > > >
> > > > > > > I am confused. When you say that the RS translates the 8B10B
> > > encoding
> > > > > > > idle characters into an /I/, are you referring to it happening
> > > within
> > > > > > > the same box or are you saying this will happen at the remote
> box
> > > that does not
> > > > > > > have XAUI?
> > > > > > >
> > > > > > > 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