RE: [EFM] Re: OAM Transport Proposal
Brad,
I made the suggestion to use the OAMiF frames for the OAMiP alarm
preambles. OAMiF is the default function and is mandatory which means that
the OAMiF frame generation function will have to be in place which ever OAM
functionality is needed at any one moment. This means that the baseline
already requires a 128 byte frame be in place, so why not use it?
Thank you,
Roy Bynum
At 01:13 PM 5/2/2002 -0700, 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.
>
>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