Voice over Frame Relay—Voice Bandwidth

In a Voice over Frame Relay (VoFR) network, the frame-relay voice-bandwidth command is used in a Frame Relay map class to set aside the bandwidth required to successfully transport the desired number of calls. This method of bandwidth provisioning operates in much the same way as IP RTP Priority and Low Latency Queuing features that reserve bandwidth for traffic flows. Unlike LLQ or RTP Priority, the frame-relay voice-bandwidth command has the capability to provide CAC. Because VoFR operates at Layer 2, Frame Relay headers can be examined to determine whether a frame is carrying voice payload or data payload. The channel identification (CID) in the voice frames is used to identify which individual frames belong with the current voice conversations in progress. Because the frame-relay voice-bandwidth command sets aside a maximum bandwidth for voice conversation, and tracks the number of conversations in progress, the frame-relay voice-bandwidth command has the capability to deny the admission of an additional conversation if the maximum bandwidth allocated to voice will be exceeded.

This CAC feature only applies when VoFR is used, as defined in Frame Relay Forum Implementation Agreement FRF 11. VoFR does not use IP, UDP, and RTP to encapsulate the voice traffic. By eliminating the need for IP and RTP/UDP headers, VoFR reduces the amount of overhead needed to transport the voice payload, as show in the following formula:

Bandwidth per call = (Payload + L2) * 8 * pps

For example, a G.729 call using 50 pps requires 10.4 kbps, as shown in the following calculation:

Bandwidth per call = (20 + 6) * 8 * 50 = 10.4 kbps

Local Voice CAC 565

Example 8-8 Frame Relay Voice Bandwidth

interface Serial0/0 encapsulation frame-relay no fair-queue

frame-relay traffic-shaping

!

interface Serial0/0.1 point-to-point frame-relay interface-dlci 100 class vofr

!

map-class frame vofr frame cir 256000 frame bc 2560 frame fragment 320 frame fair-queue

!64 kbps is enough for six G.729 calls at 10.4 kbps each. frame-relay voice-bandwidth 64000

You can implement this CAC method only if VoFR is a viable technology in your network.

Table 8-7 evaluates the VoFR Voice-Bandwidth mechanism against the CAC evaluation criteria described earlier in this chapter.

Table 8-7 VoFR Voice-Bandwidth CAC Evaluation Criteria

566 Chapter 8: Call Admission Control and QoS Signaling

Trunk Conditioning

Cisco IOS supports a function called a permanent trunk connection, sometimes called a connection trunk. A connection trunk creates a permanent trunk connection across the VoIP part of the network. To accomplish this, the connection trunk command is configured on a voice port to emulate a permanent connection across a packet network. The bandwidth required by the connection trunk is allocated at the creation of the trunk and remains reserved until the trunk is torn down. Figure 8-11 illustrates this concept.

Figure 8-11 Trunk Conditioning

Trunk conditioning is used to monitor the connection trunk state. If the connection trunk becomes unavailable, the originating gateway has the capability to signal the origination PBX and indicate that an alternate route must be found.

A unique attribute of trunk conditioning, compared to other CAC features, is that trunk conditioning has visibility into the condition of the POTS connection on the terminating side of the network and the condition of the WAN. In Figure 8-11, if there is a failure in either the WAN or the remote-side TDM connection, the originating gateway can detect this and signal the origination PBX, indicating that an alternate route must be found. This information is carried as part of the keepalive messages that are generated on connection trunk configurations.

You can tune the precise bit pattern that will be generated to the originating PBX. The ABCD bits can be configured to specific busy or out-of-service (OOS) indications that the originating PBX will recognize and act upon.

Trunk conditioning is therefore not a call-by-call feature, as are those discussed so far. It is a PBX trunk busy-back (or OOS) feature. If there is a failure in the WAN, the trunk to the originating PBX is taken out of service so that no calls can be made across that trunk until the WAN connectivity is recovered.

568 Chapter 8: Call Admission Control and QoS Signaling

Example 8-10 Connection Trunk Host Site

controller T1 1/0 framing esf linecode b8zs

ds0-group 1 timeslots 1 type e & m-wink-start ds0-group 2 timeslots 2 type e & m-wink-start clock source line

!

voice-port 1/0:1

connection trunk 1000 answer-mode

!"slave side"

!The answer-mode specifies that the router should not attempt to !initiate a trunk connection, but should wait for an incoming call !before establishing the trunk.

!

voice-port 1/0:2

connection trunk 1001 answer-mode

!

dial-peer voice 1 voip destination-pattern 100. dtmf-relay h245-alphanumeric session target ipv4:10.1.1.1 ip qos dscp cs5 media

!

dial-peer voice 2 pots destination-pattern 2000 port 1/0:1

!This dial-peer terminates the connection from the host site's voice-port 1/0:1.

!

dial-peer voice 3 pots destination-pattern 2001 port 1/0:2

!This dial-peer terminates the connection from the host site's voice-port 1/0:2.

!

interface Serial0/1

ip address 10.1.1.2 255.255.255.0 clockrate 128000

Trunk conditioning is limited in scope because it applies to connection trunk networks only.

Table 8-8 evaluates the trunk conditioning mechanism against the CAC evaluation criteria described earlier in this chapter.