VoFR

[marinaibm]

Hello,

Customer has Frame Relay based network with CIR = 0..Is there any chance to implemet VoFR (he wants only 1-2 phones to be on each of 100 sites..)without changing the CIR?

Thanks in advance

Marina

[vassatrian]

Dear Marina.

There are 2 things on my opinion:

1. If customer wants for his users to make a call and be able to communicate as humans - ”talk”, then he needs to consider QoS deployment and as I believe there are no workarounds.

2. QoS options could be LLQ for FR or IP RTP Priority:

BUT!!! you will not be able to allocate any portion of bandwidth without having CIR set to > 0

3. As a third option it is always possible to relay on burst capacity and CIR=0, but you will not be able to prioritize: you need to use probably FIFO queuing on interface.

:)

Good luck,

Vakhtang

[marinaibm]

Vakhtang....THANKS , i feel much better now :)

[bowera]

I think Vakhtang is right. This is a disaster waiting to happen !!

Andrew

PS - Hi Vakhtang .......

[marinaibm]

I know he is..thats what i told to the customer, just wanted to make sure because the answer i got was "there is another company wishing to implement that with CIR 0 and if you cant do that we ask them " :)

[pbarman]

Does the customer have a SLA from the frame-relay provider? If he has 0 CIR, but a SLA > 0, you should be able to implement VoFR without any problems.

[vassatrian]

Dear PARTHA BARMAN.

That is very interesting.

If your “committed mean transfer rate” = 0 (CIR), what sort of SLA we are talking about? Is that SLA for unguaranteed delivery of traffic bursts and what traffic bursts we are talking about - committed and exceeding bursts or above that?

Committed burst:

Bc = CIR / ”time interval” “time interval” usually 1 or 1.5 seconds

Exceeding burst:

Be = 2 x Bc

In any case service provider will be committed to support Bc and Be because routers send traffic in bursts and Bc & Be as a matter of fact do not interfere with scheduled traffic dispatching.

SP should not guarantee any bursts above Be.

Based on simple mathematical calculations, when CIR=0, we can get the result that SP probably will guarantee delivery of O Kbps with bursts of + - 0Kbps.

This mean that based on worldwide practice when CIR = 0 there is only one SLA available – “best effort” delivery.

“Best effort delivery” – this is against what we are fighting with QoS techniques. In this case with CIR set to 0 yoi will not be able to configure any prioritisation schemes.

Of course customer can probably negotiate with SP some special deals for traffic handling in the core (separate PVC for voice, some priority on the FR switch interface level for that PVC, … etc), but please take into consideration that all traffic in this case will be marked with DE but set to 1 – discard when there are problems in the network.

So the obvious question is – how often SP discards the packets and can SP give SLA/guarantees on that?

As you see it becomes more complex and further we go more variables we need to consider.

On my opinion to deploy VoX you need CIR > 0 and if there are folks outside who want to do that with CIR = 0, let them do it - God bless them.

Please feel free to correct me if I have made any wrong statements.

Regards,

Vakhtang.

PS.

Dear Marina.

I think the correct answer for your question would be:

“Theoretically it is possible. Practically you will have a lot of headaches.”

[dumartin]

Vakhtang is correct and you will have headaches. You can do VoFR with the CIR of 0. The biggest problem you will run into is QoS. When you configure QoS for voice you determine the settings off of the CIR. With a cir of 64k you will fragment your packets to 80 bytes. That works fine on a 64k line. But if you are allowed to burst to 256 as an example, your data will still be slow because the packets are being fragmented as if you were doing 64k. I would suggest you use LLQ for the QoS. That way you can try and give the voice as much priority as possible. If you dont do any fragmenting when you send a data packet of 1500 bytes you will get choppy voice with a low CIR. I wouldnt suggest configuring on the bc. If you do you will be upset with the performance when you are getting 64k instead of T1. Configuring for bc does nothing but cause issues because your network only runs the way you want it 1 minute of the day.

Here is a URL on LLQ.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfrpqfq.htm

[pbarman]

I think there is some confusion going on regarding SLA. If you have an SLA of say 128kbps, 99.8% time your traffic will pass through the frame-relay network successfully without being discarded (even though it is marked DE). Its as good as a CIR. Please find the excerpt I captured from a document at CCO itself.

"For example, at least one successful (and popular) Frame Relay service provider provides an economically attractive Frame Relay service that permits a zero-rate CIR on PVCs, combined with an SLA that ensures that at least 99.8 percent of all frame-level traffic presented to the Frame Relay network will be delivered successfully. If this SLA is not met, then the subscriber’s monthly service fee will be appropriately prorated the following month. The Frame Relay service provider provides frame level statistics to each subscriber every month, culled from the Frame Relay switches, to measure the effectiveness of this SLA “guarantee.” This particular Frame Relay service provider is remarkably successful in honoring the SLAs because they conduct ongoing network capacity management on a weekly basis, provisioning new trunks between Frame Relay switches when trunk utilization exceeds 50 percent, and ensuring that trunk utilization never exceeds 75 percent. In this fashion, traffic on PVCs with a zero-rate CIR can generally avoid being discarded in the Frame Relay network."

I agree this 0 CIR will create havoc to your VoIP network, but with a SLA 99% times you'll have no problems. And many customers these days are going for SLAs, without any problems.

Thanks,

Partha

[dumartin]

One more thing-

For 2 phones you will need 128k at g711. If you are doing g729, cRTP and VAD you can do 2 calls with about 16k. So you may want to look into that so that if you can get 64k you can still push your voice and a little data.

Here is a URL on the per call BW consumption-

http://www.cisco.com/warp/public/788/pkt-voice-general/bwidth_consume.html

[marinaibm]

Many thanks to all of you..

Marina

[bcowley]

0 CIR is a very common practice for Sprint. They claim their network is so good that you do not need it (I don't necessarily agree with that). However, I have many customer installations in which we "made up" a CIR value to input in order to implement traffic shaping. We have had reasonably good success with that. The only thing for sure is if you use traffic shaping without a CIR value in the configuration you will be sorry. For grins, just input the CIR value that you would recommed to the customer in the config and see what happens. Worst case scenario: They must obtain a CIR from their carrier (which you told them in the first place).

-Brian