From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Wed Jul 16 2008 - 09:39:43 ART
David,
The confusion with FR terminology probably arises from the fact that service
providers performs frame-relay traffic policing (FRTP) on their side while
customers perform frame-relay traffic-shaping on their side. Those are
different procedures, which use similar notation though (CIR/PIR, Bc/Be).
Also the oversubscription practice make people think what is their real CIR
value since providers guarantee one rate and still allow to send at a higher
rate :)
In short, the goal of FRTS is to limit sending rate while traffic policing
is an admission procedure. FRTP allows packet bursts which conforms to CIR
(<=Bc in size during Tc) to come in unmodified, and marks packet burst that
exceeds CIR but not PIR (fall within Bc+Be during Tc) with DE bit. Packet
bursts that exceed Bc+Be (rise over PIR during Tc) are simply dropped.
Further, exceeding packets with DE bits set *may* be dropped in SP cloud in
case of congestion or may not - there is no guarantee on those.
As I already mentioned, it's quite common tp SP to guarantee it's customers
one (smaller) traffic rate (calling this minCIR or CIR) yet allowing to send
at higher rate (calling this rate CIR or PIR - terminology is a bit messy
and confusing).
In your case it sounds reasonable to make the following assumptions:
minCIR (minimum comitted information rate) = 48Kbps,
PIR (peak information rate) =128Kbp,
EIR (excessive information rate) =PIR-CIR=80Kbps. (The rate over guarantee
which you can use in addition to minCIR)
Based on the default Tc=125ms and provided that we always want to send at
maximum possible speed:
Bc=PIR*Tc=128000*0,125=16000 bits (note that CIR is replaced by PIR in the
formula, since we constanly allow to send over guaranteed rate).
Be=0 (No need for FRTS extended burst functionality. Note that Be semantics
is different in FRTS and FRTP).
Here are the suggested traffic-shaping settings on the customer side (using
legacy FRTS syntax). Note that the configuration below constanly sends
traffic over guaranteed CIR=48Kbps (since Bc is based on PIR=128Kbps) and
throttles back to CIR when BECNs are received from the provider cloud (it
sounds reasonable to respond to BECNs, since they are natural FR signaling
mechanism)
map-class frame-relay CUSTOMER
frame-relay cir 128000
frame-relay mincir 48000
frame-relay bc 16000
frame-relay adaptive-shaping becn
This is what you could read further about FRTS/FRTP:
FRTP:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/frtp_gsr.html
FRTS:
http://www.internetworkexpert.com/resources/01700368.htm
http://blog.internetworkexpert.com/2008/01/22/legacy-frts/
http://blog.internetworkexpert.com/2008/01/24/mqc-based-frame-relay-traffic-shaping/
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344 Online Community: http://www.IEOC.com CCIE Blog: http://blog.internetworkexpert.com
2008/7/16 David Lonnie <david.lonnie@gmail.com>:
> Hi,experts: > I am confused with the frame-relay terminologies. > suppose Token bucket interval is 125ms ,that means Tc=1/8 > > 1.maximum through-put is 128K > 2.During congestion,provider will mark any traffic in excess of 48K as > discard eligible. > > > Can i regard maximum through-put as CIR or (bc+be)x1/8 ? > > During congestion,provider will mark any traffic in excess of 48K as > discard > eligible.It sounds like a guarantee that ISP provided. > I know only mincir is guaranteed by ISP, so 48K is mincir ? > > If somebody can clarify for me, or provide a link about this , i will be > very graceful. > > > Thanks in advance. > > David > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART