# 10.19 Legacy GTS for Frame-Relay

I don't know if agree with the answer key setting the "be" value to zero..  The solutions guide states the following

In this particular task the service provider instructs the customer that the guaranted rate (mincir) is 96k and the desired average rate

is CIR(128k).   Using the formula to get bc we do Cir*tc/1000 or 3840 and then for burst we do air-cir*tc/1000 whic gives us  960

so we have

bc=3840

be= 960

we set mincir to adapt to becn and reducing sending rate to 96000

okay so if you run through the math under those circumstances be+be will never exceed cir over the second

if we allow bursting or don't allow for bursting over the second we still never send more than the cir and traffic can still get marked with DE regardless

so i'm confused as to how setting be to zero would affect the traffic drop in the cloud if the cloud is signaling DE on everything above 96

Anyone have anyone thoughts on this.

• BLP - I can put might thoughts on it and maybe we can both come to the
same conclusion.

"and then for burst we do air-cir*tc/1000 whic gives us 960"
- I don't know how you came up with this formula for Be. And you got
Bc/4=960. If I would do Be it would be 1 or 1,5s.

"okay so if you run through the math under those circumstances be+be
will never exceed cir over the second"
- When there is Be involved we technically can use more BW over
second that CIR.

"if we allow bursting or don't allow for bursting over the second we
still never send more than the cir and traffic can still get marked
with DE regardless"
- I think minCIR (96k)=CIR and CIR(128k)=PIR in this case.

"so i'm confused as to how setting be to zero would affect the traffic
drop in the cloud if the cloud is signaling DE on everything above 96"
- #1 I think that DE bit might not automatically result in a drop.
It's more like lower preference, i.e. DSCP 11 vs 12.
- #2. If traffic is over PIR (128k) that should result in FECN and
BECN and in traffic to be limited to CIR (96k). The Be of zero in this
case does not allow for bust in a traffic. I.E. if application sends 0
traffic in first 30ms, but 3841 bits in next 30s, that would be
constituted as violation resulting in FECN/BECN. Value other than zero
would be more application/burst friendly.

Andrius
• Thanks for your response andrius,

I don't know how you came up with this formula for Be. And you got
Bc/4=960. If I would do Be it would be 1 or 1,5s.

I assumed air = 128 in this case was used for air and 96 was used for cir with a 30ms interval  which 128-96*30 = 960 ( which was purely an assumption becuase there was no indication of what the access rate was, so i know could've been off)

As a follow up, Brian Dennis basically told me "be" in this case was set to zero simply because the question never requested it.

- When there is Be involved we technically can use more BW over
second that CIR.

from my understanding / interpretation of shaping from the instructors was regardless of what you set your be to you still never send more than cir over the second

#1 I think that DE bit might not automatically result in a drop.
It's more like lower preference, i.e. DSCP 11 vs 12.

I agree with you on that.

• I don't know if agree with the answer key setting the "be" value to zero..

In this task configures cir at customer router is actually the pir for the SP . Any traffic above cir in the form of Be sending from customer to SP will simply drop. So there is no point of setting Be above 0

• The task asks that the traffic exceeds 96kps and lower than 128kps should be marked with DE, Does the SG satisfy that?I don't think so..

does the adptive shaping of 96000 mark traffic higher than that? no, it is by definition that the adatpive shaping lowers the rate to the minCIR and doesn't allow higher than that.

I think the CIR should be 96000 and the Be 960