ATM Switch Interoperability
Martin, Christian
CMartin at mercury.balink.com
Wed Jan 20 21:14:43 UTC 1999
Steve,
In your experience, then, would you agree that higher SCR rates should
have higher MBSs, so that the Burst Tolerance linearly increases with
SCR? I have a problem with an MBS of 100 for SCR 1000 up to 1000000.
CDVT gives us some bucket depth, but I don't think we're clumping. The
LS1010 doesn't shape VBRnrt, just polices. At the far end is a Fore
ASX1000. So, we have three different vendors in the mix. Our ATM
provider sets MBS to 100 no matter the contract. This seems too
restrictive.
Chris
>
> Here is the function for the relationship of Burst Tolerance
> BT (time) and Maximum Burst Size MBS
> (a number of cells). Most switches allow you to set the MBS
> and then they calculate the BT based
> on this function. Definitions: Ts = 1/SCR, Tr = 1/PCR, ts = BT
>
> MBS = | 1 + ((CDVT + ts) / (Ts - Tr)) | where |x|
> stands for the largest integer less than x.
> for Tr > 1 and CDVT > Tr -1.
>
>
> This function is based on using a unit of micro-seconds for
> each variable. The corresponding function is used
> to calculate the maximum burst size B (a number of cells) on
> the PCR policing:
>
> B = | 1 + ((CDVT) / (Tr - 1)) | For Tr > 1 where
> |x| stands for the largest integer less
> than x. CDVT must be greater than Tr - 1.
>
> This function is also based on units of micro-seconds. It
> breaks down if Tr < 1 microsecond. At that point a smaller
> unit of time would need to be subtracted from Tr instead of 1
> microsecond. This only matters with very large PVCs
> with a PCR of over 1000000 cells per second.
>
> These values for MBS and CDVT are usually defaulted for the
> user and the same default applies no matter what
> the SCR and PCR values are. Some ATM providers set the CDVT
> and MBS very low and adjust up if problems like
> you are observing appear.
>
> If the lightstream does traffic shape properly this should
> not be an issue. If you do have traffic shaping on the lighstream
> you could set the PCR=SCR. You will lose a small amount of
> burst but will be able to sustain at SCR. The bursts do not
> really buy you a large amount of extra traffic anyway (unless
> CDVT and MBS are set high) they are really just there to
> allow for variations in accuracy of policing between devices.
>
> Steve Murray
> MCI Worldcom
> steve.murray at wcom.com
>
>
> >>> "Martin, Christian" <CMartin at mercury.balink.com> 01/15 9:19 PM >>>
> >We have it matched to the policing policy of the Network
> Provider. By
> >increasing the CDVT, we gain some bucket depth, but we are
> only MUXing 5
> >VCCs over one VP. There shouldn't be too much clumping, espescially
> >considering the load on the switches(low). One thing is interesting,
> >though: The far end (customers) are all running over DS3 using HEC
> >delineation.
> >
> >A curiosity: Given the parameters below for the contract,
> particularly
> >the MBS and CDVT, does it appear that we are being cheated? From my
> >understanding of the UNI 3.1 spec, the MBS should be adjustable
> >according to SCR/PCR, given the fact that CDVT is defined as the same
> >for both SCR and PCR buckets.
> >
> >One obstacle that myself and my colleagues have not been able to
> >overcome is the use (aside from bucket calculation) of the Burst
> >Tolerance. It is obviously proportional to the MBS, but again, it
> >appears as if a contract specifying a PCR/SCR of
> 100000/50000 cells per
> >sec, should have a higher MBS than a 10000/5000 cell/sec contract.
> >
> >Any insights?
> >
> >Chris
>
>
>
> -
>
>
More information about the NANOG
mailing list