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
At 01:32 PM 9/21/01 -0700, Andrew Smith wrote:
>Tony,
>
>Actually, I think the real issue is not whether it is bandwidth-limited, at
>least as I understand the term, but whether there is a mechanism to
>guarantee it some pre-configured amount of bandwidth.
>
>I would strongly assert that nobody here can come up with a number of bits
>per second, packets per second or whatever units are desired, that will be
>appropriate for all EFM deployments. That implies that you'd better make it
>configurable and also give it some sort of token bucket scheduler to
>accomodate the burstiness that is highly likely with this OAM traffic. You
>probably also want to allow the OAM "channel" an unfair advantage in the use
>of spare bandwidth too, implying some sort of priority in the scheduler too
>(go read some of the Class-Based Queueing work from Van Jacobson et al. for
>more information on such schedulers). To think of the OAM channel as a CBR
>stream is very unrealistic.
>
>Now, the well-read amongst you will find this description quite familiar:
>these are the sorts of schedulers that have been widely implemented for the
>last 5 years or so, in silicon at gigabit and higher speeds, in switches and
>routers. I'd bet that 80% or so of all packet switches sold today have these
>schedulers built into them and they are far more flexible than anything that
>people would want to build into EFM PHY-layer silicon. End stations, also,
>tend to include such schedulers in their network drivers (Win2000, WinXP,
>Solaris, Linux etc.). To demand that EFM PHY include another copy of such
>schedulers is to add unnecessary complexity and to handicap the EFM standard
>at the starting line.
>
>Summary: leave the mechanisms for getting OAM traffic onto the link as an
>implementation issue - standardise only the content of the messages and
>their protocol interactions.
>
>Andrew Smith
>
>
>
>
>-----Original Message-----
>From: owner-stds-802-3-efm@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Tony
>Jeffree
>Sent: Friday, September 21, 2001 1:51 AM
>To: mattsquire@xxxxxxx
>Cc: stds-802-3-efm
>Subject: Re: [EFM] OAM - Faye's seven points
>...
>At 20:16 20/09/2001 -0400, Matt Squire wrote:
>
>
> >Both OAM and data traffic travel over the same medium. No matter how we
> >slice it, OAM traffic does reduce the bandwidth available to the user.
>
>Absolutely. Unless you are talking about OAM being carried on a separate
>physical medium, arguments about side band vs frame based solutions seem to
>me to be somewhat spurious. The real issue here is whether the OAM traffic
>is bandwidth-limited or not.
>...