RE: [EFM] Re: OAM Transport Proposal
Rich,
You're alive! ;)
By the way, in response to a previous email of yours, I was aware the Kevin
Daines is working to enhance the OAM baseline. We have talked a little bit
about it.
I agree that protection, failover, alarms, etc. are important between the CO
and the residence. That is why I'd advocate a state machine in a sublayer
that is similar in specification to the way Clause 37 operates between the
receive and transmit sides of the PCS. This would involve a lot fewer
changes to existing clauses. The state machine would offer fast response
time to these messages/alarms in a timely fashion while reporting to the
management entity via the MDIO/MDC in a non-timely fashion.
As for comparing the link messages in 10GbE with the 8-byte preamble
message, there is a huge difference. The LF/RF messages in 10GbE are placed
in the IPG, not the preamble. 10GbE doesn't touch the preamble at all. The
10GbE link messages also don't require a CRC because we use multiple
transmissions and hysteresis to determine the data. And, 10GbE doesn't do
P2MP. I am concerned about sending out the 8-byte preamble without an
Ethernet frame. I just get a gut feeling that this is going to cause a lot
more problems than it is worth, for various reasons that I've already
stated. If the task force could find a way around needing the 8-byte
preamble message, I think there would be a higher level of comfort from a
lot of people. Maybe all we need to do is enable periodic MAC control frame
transmission, or go with the assumption that higher layer protocols such as
TCP/IP will always be performing some messaging even if the link slows down.
Cheers,
Brad
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Thursday, May 02, 2002 2:13 PM
Cc: stds-802-3-efm@ieee.org
Subject: Re: [EFM] Re: OAM Transport Proposal
Brad,
Some feedback to your comments:
Best Regards,
Rich
--
"Booth, Bradley" wrote:
>
> Just a few comments below:
>
> Thanks,
> Brad
>
> -----Original Message-----
> From: Matt Squire
[mailto:mattsquire@xxxxxxx]
> Sent: Tuesday, April 23, 2002 10:29 PM
> To: stds-802-3-efm@ieee.org
> Subject: [EFM] Re: OAM Transport
Proposal
>
> Another attempt to address multiple
questions at one time.
>
> 1) MDIO slowing preamble down. The intent
is that the any
> bit handling
> of the preamble is done below the MDIO
interface. One of
> the reasons,
> for me anyway, to keep the use of preamble
to communicating
> a few very
> specific states was for this point
exactly. Trying to
> communicate real
> 'data' would be slowed down by getting the
data from the
> MDIO
> interface. The assumption is that the RS
is enhanced to
> hold a small
> number of state variables which can be
communicated via the
> preamble
> without turning into management frames
over MDIO.
>
> BJB> Using the RS for the preamble will
bypass the need for
> use of the MDIO. I just want to be sure that we do
clarify that "pervasive
> access" does not mean instantaneous or high-speed access.
I believe David
> Law's term "pervasive" means that the MAC, MAC Control and
RS all have the
> same direct access to the MIBs rather than via MDIO. The
management entity
> would have the same speed of access to the MAC Control MIB
data as it would
> to the RS MIB data. Therefore, the only way the RS can be
more responsive
> than MAC Control is if there are state machines in the RS
to handle OAMinP
> without management intervention.
[RT] We're talking about responding to bits, such as fault
and alarm
here. These conditions may be reported via MIB or MDIO/MDC
for
posterity. However, the real value is in fast processing of
these
conditions for protection, failover, etc. EFM may go to the
residence,
but the residence is attached to the central office. That's
where
protection and failover are important.
> 3) Null/Dummy frames screwing up MIBS.
Yes semantics of the
> undersized
> frames variable will have to change to say
something like
> "except for
> null/dummy frames which are counted by
...". But I think
> things can be
> defined in a way thats backward
compatible. This, along with
> only using
> those frames when the other side supports
it, should have
> the effect of
> MIB compatibility.
>
> BJB> I get the feeling that there are a
lot of people that
> would rather live without this feature.
[RT] Let's stop calling them frames then. These OAM reports
don't go to
the MAC and are merely 8-byte link messages not much
different in nature
than 10GbE's Local Fault/Remote Fault 4-byte messages.
> 4) Clauses effected. We did a preliminary
examination of
> the clauses
> that needed to be addressed by the
proposal. The following
> is the list
> as I see it.
> - Clause 30 (Management). New MIB
objects, enhanced
> locally and also
> enhanced to include peer info.
> - Clause 31 (MAC Control). Add OAM
section, fraem
> formats, protocol
> operation, bla bla bla
> - Annex 43B. Add OAM types to slow
protocols list, maybe
> change slow
> protocol definition, etc.
> - Clauses 22 & 45. New PHY monitoring
registers for
> things like RX
> power, signal-to-noise ration, etc.
> - Annex 30A & 30B. New OIDs for managed
objects.
> - Clause (new). OAM preamble byte
format, use,
> description, etc.
> - Clause 22 & 35 (RS/MII, RS/GMII) -
Dummy/null frame
> generation,
> inclusion of preamble transport
capability.
> The preamble specific changes are the
latter two. Please
> point out if
> we're missing some clause changes
somewhere. This list does
> not reflect
> which clause changes are significant and
which are minor.
>
> BJB> Do you have a list of clause editors
to perform these
> modifications?
>
> - Matt
>
---------------------------------------------------------
Richard Taborek Sr. Intel Corporation
XAUI Sherpa Intel Communications Group
3101 Jay Street, Suite 110 Optical Strategic Marketing
Santa Clara, CA 95054 Santa Clara Design Center
408-496-3423 JAY1-101
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com