Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] OAM - Faye's seven points


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-----
[]On Behalf Of Tony
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.