[Fwd: [EFM] OAM - Faye's seven points]
And equally (or more) important, we're talking about a few packets a
second (re: the slow protocols proposal).
Matt Squire wrote:
>
> I'm not sure I understand this. If you can crank up the bit signal rate
> to accomodate OAM, then could you not crank it up equally to accomodate
> more user data?
>
> In all methods, the OAM bits are taken from the overall # of bits that
> go down the medium. To me, the 'revenue' traffic is all of the bits
> available after OAM is accounted for (minus packet overhead minus other
> overhead). This is independent of whether the OAM is @ the PHY, MAC, or
> higher.
>
> - Matt
>
> Roy Bynum wrote:
> >
> > Matt,
> >
> > You forget, if the OAM is in the side band, the bit signal rate can be
> > increased to accommodate the additional bandwidth used by the OAM
> > overhead. If the OAM is at the MAC above the existing PCS, then the
> > bandwidth will have to be taken from the revenue traffic.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 08:16 PM 9/20/01 -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.
> > >One way to cap that effect is to use a dedicated side-band with a
> > >limited bandwidth. An alternate way to cap the effect is to
> > >police/shape the OAM traffic at a layer above. A third alternative is
> > >to use something like a slow protocol which is limited to 5 frames/sec.
> > >