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

[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.
> > >