Packet Delay on Frame PVC for Voice

[b.devillier]

I have a frame relay interface with two sub interfaces, each with PVCs to different locations. A route map tags voice traffic by UDP port, and routes next hop on one PVC dedicated for voice. All other traffic passes on the data PVC. LLQ is used on the sub prioritizing voice RTP, and signaling. I see no FECN/BECN, I'm at 11% CIR on the voice PVC, yet I still see packet delay. I am fragmenting on the interface, and processor is not being taxed. Average call jitter is 65ms + because of this delay, and CMR reports packet loss. Any one have experience with multiple PVCs and LLQ?

[Phillip Remaker]

Is there possibly a problem with the frame relay provider? What ping response times do you have on the data PVC? Who is the frame relay provider?

[b.devillier]

This was my initial concern. Ping response times for the most part are 4-8ms, but with an extended ping, there is some latency (up to 400). It is inconsistent. Verizon says (of course) that they see no problems. There are no frame drops, and they don't see the delay from the level I guys perspective.

[RON ROYSTON]

be sure you have the "bandwidth" command set propoerly on the main interface and subinterfaces.

Also, apply the service-policy to a frame-relay mapclass. Apply the FR map class to the PVC under interface-DLCI config mode.

disable becn, set your fragmentation size assuming the smallest link on any PVC riding the physical ports (even at the remote).

Let me know if that helps. Lastly, enable CEF and be sure that you've enabled FR traffic shaping on the main serial interface.

[b.devillier]

I already have this done as well. My suspect is that one of the PVCs on the data side may be over subscribed on the far end, but I don't understand the queueing mechanism well enough to understand the impact that would have on another PVC sharing that interface. I've also had a recommendation to use PIPQ, but as I understand it, that alleviates my alternate routing QOS for voice traffic because it is all or nothing on one PVC. Thanks for the response.

[RON ROYSTON]

My nderstanding of fragmentation is that it is done to overcome problems with serialization delay on links slower than 768k. In other words, we need to chop up large frames and interleave small voice frames between the large data ones.

Because all PVC's share the same interface, serialization delay from one PVC affects the others. What is the port speed of the routers on all ends of your FR network? The port speed = how many channels of the T1 you are using (look under the service-module t1 timeslots 1-x if you have the integrated CSU/DSU).

[b.devillier]

Port speed on all devices is full T1. Problem is going to be that the data head end router is over subscribed and out of my control.

[b.devillier]

Also, The 7507 router at the head end will not take the fragmentation setting that I feel is correct. On a 768K link, you should fragment at 960. The 7507 will only take increments of 8, not 10ms.

Thanks-

[RON ROYSTON]

What do you mean only take increments os 8, not 10ms? You don't tell the router how many ms on FR configurations, you fragment and tell the router Be, CIR, and Bc. The router does the math.

I think you should call you local Cisco reseller to get an engineer to fix it for you. Like you carrier, I believe that the issue is with the CPE (your routers configurations).

God luck.

[b.devillier]

I am the partner. Disregard the ms on the previous post, mispoke- if you look at fragmentation settings on the router, an easy formula is # of DS0 required for CIR * 80. So for 768K link, it's 12 * 80, or 960. The 7507 will not take 960, it will only take a number divisible by 8. I've never seen this before, but it will not take the command for the fragment size that the formula specifies. So, my question is what makes the 7507, running 12.1, require a different fragmentation than the 3640 this is configured on?

[dragos.stroescu]

Hello there,

We got some pretty much experience in VoIP over FR as we have implemented more than one solution.

My understanding is that you have on the same phisical interface different FR PVC's for voice and data.

To make it work correctly from the CPE perspective you have to:

- prioritize the VoIP traffic by using PIPQ (in fact you have to prioritize the Voice PVC);

- fragment the data into the data PVC according to size/bw rules to avoid the jitter.

- Be should be 0 for the voice PVC (your side);

- Tc on CPE side is recommended to be about 10 times smaller than the Tc on the SP side (don't ignore that rule) e.g. 10ms on CPE and 100ms on SP side;

If you correctly configure the above recomendations and the router is doing the job (no bugs) all should work fine (if the SP offered CIR/Bc/Be is real...)