VoIP over Frame Relay with Multipoint PVCs and Prioritization

Introduction

This document discusses traffic shaping and prioritization for a Voice over IP (VoIP) over Frame Relay network with hub and spoke topology. The configuration of the hub is such that there are two permanent virtual circuits (PVCs), one for each remote spoke, and both data and voice are sent over the same PVCs. It is important to note that the prioritization and fragmentation discussed in this document applies not only to this scenario but also to a scenario where you may have one PVC with voice and data and another with only data. The data PVCs need to be traffic-shaped just as the voice and data PVCs. This is due to the fact that when a single physical pipe is shared, in this case at the hub, the serialization delay affects all data.

In the topology below, New York represents the hub central router. Raleigh and San Jose represent remote routers connected to the hub through a Frame Relay network. There are two PVCs that connect to the New York router. In this case, New York should never send more than 64 kbps to Raleigh and likewise, it should never send more than 192 kbps to San Jose because this exceeds the configured Committed Information Rate (CIR) on the Frame Relay mapclass.

In the topology shown in this document, the routers with VoIP configurations are directly connected to a Frame Relay cloud. In some topologies, however, the voice-enabled routers can exist anywhere in the network, with the exception of the Cisco AS5300. For more information on this, refer to the note provided. The voice routers can be connected through LAN connectivity to other routers that are connected to the WAN. This is important to note because if your voice routers are not directly connected to a Frame Relay service, all WAN connectivity configuration commands are configured on those routers that are connected to the WAN, and not on the voice routers.

Note:  Cisco AS5300 routers with high-speed serial interfaces are not designed to support data connection to a WAN. You need to use your Cisco AS5300s as intermediate LAN routers with the main functionality to process voice calls. You need dedicated routers to act as direct connections to the WAN.

Prerequisites

Requirements

Before you attempt this configuration, ensure that you meet these prerequisites:

• Basic understanding and configuration of Frame Relay Traffic Shaping (FRTS)

• Basic understanding and configuration of VoIP

Components Used

The information in this document is based on these software and hardware versions:

• Three Cisco 3640 routers with Cisco IOS® Software Release 12.3(5) Enterprise Plus

• Four analog phones connected to Foreign Exchange Station (FXS) ports on spokes

• One PBX connected to a T1 controller on the hub router

The spokes can also be a Cisco 2600 or a 1750 platform. The hub can be a Cisco 2600 or 3600 platform in the case of digital voice, but it can also be a Cisco 1750 platform if only analog voice exists at the hub. All traffic shaping and configurations apply to other platforms as well.

Note: Though this document is not restricted to specific software, some of the commands used here are not available with all Cisco IOS Software versions. For example, the frame-relay fragment command is supported with IP Plus but not by an IP image.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Configuring Traffic Shaping and Prioritization for a VoIP over Frame Relay

When you run VoIP over Frame Relay, it is important that the traffic sent over the frame stays at a level that is less than or equal to the Frame Relay CIR. The router does not send traffic that exceeds the CIR when configured with Frame Relay Traffic Shaping (FRTS) as shown. If you configure the router to run at a speed greater than the CIR , you may experience voice quality issues, and voice quality is not guaranteed when you run PVCs above the guaranteed CIR.

Note: It is possible to configure adaptive shaping to enable a router to throttle down the transmission rate to a specified value if Frame Relay packets are received with the backward explicit congestion notification (BECN) bit set. You are advised however, that traffic rates are not to exceed the CIR of the Frame Relay service when voice packets are transmitted. This is to ensure proper quality and delivery when real time voice packets are sent across the network. The configuration where the CIR is exceeded is only recommended for data PVCs that do not carry voice traffic.

Note: Also, before you can configure your router to use VoIP, it is best if you understand the Quality of Service (QoS) features in Cisco IOS Software. To learn more about QoS features, refer to Queuing, Traffic Shaping, and Filtering and Fragmentation for Voice.

Note: Use the Command Lookup Tool (registered customers only) to find more information on the commands used in this document.

Network Diagram

This document uses the network setup shown in the diagram here:

Configurations

This document uses these configurations:

• New York Hub Router

• Cisco 3640 Raleigh

Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname newyork
!
logging buffered 50000 debugging
enable secret < password > [Choose a strong password with 
at least one capital letter, one number, and one special character.]
!
controller T1 2/0
framing esf
linecode b8zs
ds0-group 1 timeslots 1-4 type e&m-wink-start
!
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay traffic-shaping

!--- This CLI command enables traffic shaping for both PVCs.

!
interface Serial2/0.1 point-to-point
description Connection to Raleigh PVC
ip address 172.16.120.2 255.255.255.0
  frame-relay interface-dlci 100
  class class-raleigh
!
interface Serial2/0.2 point-to-point
description Connection to San Jose PVC
ip address 172.16.130.2 255.255.255.0
frame-relay interface-dlci 200
  class class-sanjose
!
ip classless
!
map-class frame-relay class-raleigh
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80

!--- Recommended fragment size for 10ms delay when carrying voice !--- traffic based on the configured CIR 64000. !--- based on the configured CIR 64000 
 frame-relay ip rtp priority 16384 16383 48

!--- Two calls with g729, no CRTP, at 24 kbps/each. 
 !
map-class frame-relay class-sanjose
 frame-relay cir 192000
 frame-relay bc 1920
 frame-relay be 0
 frame-relay mincir 192000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 240

!--- This is the recommended fragment size for 10ms delay when carrying voice traffic !--- based on the configured CIR 192000.

frame-relay ip rtp priority 16384 16383 48 

!--- Two calls with G729, no Compressed Real Time Protocol (cRTP), at 24kbpseach. 
!
!
voice-port 2/0:1
!
dial-peer cor custom
!
dial-peer voice 100 pots

!--- Calls to the Public Switched Telephone Network (PSTN). 
 destination-pattern 212.......
prefix 212
port 2/0:1
!
dial-peer voice 200 pots

!--- Calls to the corporate network-four digit extension forwarded. 
destination-pattern 567....
 port 2/0:1
!
dial-peer voice 110 voip

!--- Calls to Raleigh.

destination-pattern 919392....
session target ipv4:172.16.120.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
dial-peer voice 210 voip    
!--- Calls to San Jose. 
destination-pattern 408527....
session target ipv4:172.16.130.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end  

The ip qos dscp command was introduced in IOS version12.2(2)T to replace the ip precedence (dial-peer) command.

The frame-relay ip rtp priority command reserves a strict priority queue for a set of Real-Time Protocol (RTP) packet flows that belongs to a range of User Datagram Protocol (UDP) destination ports.

Note: Because the frame-relay ip rtp priority command gives absolute priority over other traffic, use this command with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all of the excess traffic is dropped.

Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname raleigh3640a
!

logging buffered 50000 debugging
enable secret < password > [Choose a strong password with at 
least one capital letter, one number, and one special character.]
!
no ip subnet-zero
!
!
!
!
voice-port 1/0/0
!
voice-port 1/0/1
dial-peer voice 1 pots
 destination-pattern 9193924100
port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 2126789001
  ip qos dscp cs5 media
 dtmf-relay h245-alphanumeric
 session target ipv4: 172.16.120.2 
!

interface Loopback0
 ip address 172.16.125.1 255.255.255.255
 no ip directed-broadcast
!

interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial2/0.1 point-to-point
description Connection to New York
 ip address 172.16.120.1 255.255.255.0

 frame-relay interface-dlci 100
  class fr_class_voip  
!
!
ip classless
no ip http server
!
!
map-class frame-relay fr_class_voip
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment  80


!--- The recommended fragment size for 10ms delay when carrying voice traffic.


!--- based on the configured CIR 64000. 

  frame-relay ip rtp priority 16384 16383 48
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

Verify

This section provides information you can use to confirm your configuration works.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

• show frame-relay fragment —Displays information about the Frame Relay fragmentation that takes place on the Cisco router.

• show traffic-shape queue —Displays information about the elements queued at the virtual circuit (VC) data-link connection identifier (DLCI) level. This command is used to verify the operation of IP RTP priority over Frame Relay. When the link is congested, voice flows are identified with a weight of zero. This indicates that the voice flow is using the priority queue. Refer to the sample output provided.

• show frame-relay pvc [dlci#]—Displays information such as traffic shaping parameters, fragmentation values, and dropped packets. Refer to the sample output provided here and also refer to Comprehensive Guide to Configuring and Troubleshooting Frame Relay for further information.

newyork#show frame-relay fragment

interface   dlci   frag-type   frag-size   in-frag   out-frag   dropped-frag
 
Serial1/0.1 100    end-to-end    80          16        20           0 

Serial1/0.2 200    end-to-end    240         12        10           0 

newyork#show traffic-shape  serial 2/0.1
Interface Se2/0.1

     Access    Target   Byte   Sustain   Excess   Interval    Increment    Adapt
VC   List      Rate     Limit  bits/int  bits/int (ms)        (bytes)      Active

100            64000    80     640       0         10          80          -
  

newyork#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0.1 dlci 100
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
     Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 16 kilobits/sec

Traffic queued in shaping queue on Serial2/0.2 dlci 200
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
    Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 144 kilobits/sec

newyork#show frame-relay pvc 100

PVC Statistics for interface Serial2/0 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.1

input pkts 1078          output pkts 1078         in bytes 157792
out bytes 172284         dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 28        out bcast bytes 8498
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:27:48, last time pvc status changed 00:27:48
Queueing strategy: weighted fair
Current fair queue configuration:
	Discard     Dynamic      Reserved
	threshold   queue count  queue count
		64          16           0
Output queue size 0/max total 600/drops 0
fragment type end-to-end        fragment size 80
cir 64000     bc   640       be 0         limit 80     interval 10
mincir 64000     byte increment 80    BECN response no  IF_CONG no
frags 2707      bytes 172284    frags delayed 2707      bytes delayed 172284
shaping inactive
traffic shaping drops 0
ip rtp priority parameters 16384 32767 48000

Troubleshoot

This section provides information you can use to troubleshoot your configuration.

Troubleshooting Procedure

Here is troubleshooting information and instructions relevant to this configuration:

1. Troubleshoot the Frame Relay and QoS implemented for voice and ensure its correct operation.

2. Proceed to voice call failure troubleshooting as necessary.

   Note: For more detailed troubleshooting information, refer to VoIP over Frame Relay with QoS (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority).

Troubleshooting Commands

The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.

Note: Refer to Important Information on Debug Commands before you use debug commands.

• debug priority —Displays priority queueing (PQ) events and shows if a drop occurs in this queue. For more information, refer to Troubleshooting Output Drops with Priority Queuing.

• debug frame-relay fragment —Displays event or error messages related to Frame Relay fragmentation. This command is only enabled at the PVC level on the selected interface.

  newyork#debug priority 
  Priority output queueing debugging is on
  newyork#ping 172.16.120.1
  Type escape sequence to abort. 
  Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds: 
  !!!!! 
  Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
  newyork# 
  *Mar  1 05:11:24.746: PQ: Serial2/0 output (Pk size/Q 104/2)
  *Mar  1 05:11:24.754: PQ: Serial2/0 output (Pk size/Q 104/2) 
  *Mar  1 05:11:24.810: PQ: Serial2/0 output (Pk size/Q 104/2)
  *Mar  1 05:11:24.818: PQ: Serial2/0 output (Pk size/Q 104/2) 
  *Mar  1 05:11:24.874: PQ: Serial2/0 output (Pk size/Q 104/2) 
  *Mar  1 05:11:24.882: PQ: Serial2/0 output (Pk size/Q 13/0) 
  
  newyork#debug frame-relay fragment interface serial 2/0 100
  This may severely impact network performance.
  You are advised to enable no logging console debug. Continue?[confirm]
  Frame Relay fragment/packet debugging is on
  Displaying fragments/packets on interface Serial2/0 dlci 100 only
  
  *Mar  1 20:58:32.838: Serial1/0.1(o): dlci 100, tx-seq-num 3645, 
  B bit set, frag_hdr 03 B1 9C 3D
  *Mar  1 20:58:32.846: Serial1/0.1(o): dlci 100, tx-seq-num 3646, 
  E bit set, frag_hdr 03 B1 5C 3E
  *Mar  1 20:58:32.890: Serial1/0.1(i): dlci 100, rx-seq-num 17, 
  exp_seq-num 17,B bit set,
  	 frag_hdr 03 B1 80 11
  *Mar  1 20:58:32.894: Serial1/0.1(i): dlci 100, rx-seq-num 18, 
  exp_seq-num 18,E bit set,
  	 frag_hdr 03 B1 40 12

Related Information

• show Commands for Frame Relay Traffic Shaping
• Frame Relay IP RTP Priority
• Configuring and Troubleshooting Frame Relay
• Frame Relay Traffic Shaping for VoIP and VoFR
• Voice Technology Support
• Voice and Unified Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support & Documentation - Cisco Systems