RE: [EFM] OAM - Faye's seven points
Andrew,
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.
Thank you,
Roy Bynum
At 05:53 PM 9/21/01 -0700, Andrew Smith wrote:
>Roy,
>
>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
>
>
>Andrew,
>
>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