RE: [EFM] OAM - Faye's seven points
Yes to all of the below. If by a "scheduler" you are referring to "every x
'revenue whatever' an 'OAM whatever' is inserted regardless of whatever is
happening and without effecting whatever is happening in the 'revenue
whatever' and the 'OAM whatever' is not effected by the 'revenue whatever'".
At 06:31 PM 9/21/01 -0700, Andrew Smith wrote:
>You're not being clear: when you say "constant", over what interval do you
>measure: one Frame? one Byte? one Bit? the time it takes for an electron to
>jump from one atomic orbit to another? It doesn't matter which one of these
>you choose, you still need a *scheduler* to put the bits of your message (I
>assume that your OAM messages are more than one bit long) onto the medium.
>P.S. Please let me buy you lunch someday.
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Friday, September 21, 2001 5:46 PM
>Subject: RE: [EFM] OAM - Faye's seven points
>A "side band" is a constant bandwidth facility. Most of what you are
>referring to only would apply to an in-band, "frame" based OAM. It does
>not apply to a "side band" OAM channel.
>At 05:53 PM 9/21/01 -0700, Andrew Smith wrote:
> >I think we're talking past each other here (see Tony's lunchtime comment).
> >Implementation of a "side-band" channel *requires* a scheduler and queueing
> >of its own. The side-band method is the one that adds the unneeded
> >complexity by mandating an additional scheduler on top of the ones used by
> >higher layers that (in any reasonably designed piece of EFM gear) will
> >already be present.
> >I challenge this group to come up with appropriate dimensions for such a
> >side-band channel - what peak or sustained bandwidth? what burst size? -
> >that does not cause EFM to become an evolutionary dead-end.
> >Andrew Smith
> >-----Original Message-----
> >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> >Sent: Friday, September 21, 2001 3:53 PM
> >To: ah_smith@xxxxxxxxxxx; Tony Jeffree
> >Cc: stds-802-3-efm
> >Subject: RE: [EFM] OAM - Faye's seven points
> >What you are referring to in the need for "sort of token bucket
> >scheduler", and "...want to allow the OAM "channel" an unfair advantage in
> >the use of spare bandwidth too, implying some sort of priority in the
> >scheduler" would only apply if the OAM were "frame" based. If the OAM were
> >a "side band", or "out-of-band" to the revenue traffic, the all of that
> >complexity is unneeded.
> >With an OAM "out-of-band" channel, the OAM bandwidth is predetermined by
> >the bandwidth of the "side band" data. It would also not interfere with
> >the revenue bandwidth.
> >Thank you,
> >Roy Bynum