Re: [EFM] Re: OAM Transport Proposal
Brad,
OK. Let's get down to convincing you and the rest of our audience that
OAMinP is good stuff! I'll insert my comments inline below.
Best Regards,
Rich
--
"Booth, Bradley" wrote:
>
> 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.
State machines aren't the solution. One of the primary reasons for the
fast response afforded by OAMinP is to be able to implement higher level
functions like protection switching. Protection switching involved more
than one device and a switching mechnism. That's why I've been saying
that it's beyond the scope of EFM and 802.3 to specify the managment
funcionality inherent in the switching mechanism. I believe that
specification of the corresponding management service interface is
adequate. I agree with parallel reporting of faults and alarms 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.
10GbE LF/RF is a huge step forward in terms of link initialization/fault
reporting for Ethernet links. In fact, I proposed a similar mechanism
for Gigabit Ethernet, based on Fibre Channel link initialization and
fault reporting back in 1996, but I was voted down and we wound up with
Auto-Negotiation and broken RF protocol. I consider that water under the
bridge. However, even 10GbE LF/RF is somewhat inflexible as it's an "all
or nothing protocol". Basically, either a 10GbE link is up and capable
of MAC data transport, or it's down, not capable of data transport and
only capable of LF/RF transport.
OAMinP is completely non-intrusive. Assuming that the link is not
completely dead broke, 8-byte OAM messages can be sourced in either link
direction to indicate fault or alarm conditions without affecting
customer data bandwidth. CRC is employed since the messages are more
complex than LF/RF ordered sets. EFM OAM must also support P2MP and you
point out. This will likely add additional complexity. The 8-byte OAM
messages are extremely simple as you can see by the OAM baseline
proposal. The 8-byte messages are built by hardware and queued for
transmission. The messages are dequeued and transmitted at the beginning
of the next packet, or when enough IPG has been buffered (~20 bytes) in
the absense of packets. I just don't buy the FUD about "going to cause a
lot more problems than it is worth". Periodic MAC control frames, TCP/IP
and most other non-Layer 1 solutions are all either too slow, too
cumbersome, out of scope, or all of the above to handle critical OAM
fault and alarm conditions.
> 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
---------------------------------------------------------
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