|
|
This section describes how to configure VoFR, including the Cisco implementations for FRF.11 and FRF.12. The following major tasks are covered and are divided into the following sections:
This section specifically describes the commands to configure VoFR applications. It is assumed you have already configured your Frame Relay backbone network, including the map class and the LMI. For more information about Frame Relay configuration, see the Wide-Area Networking Configuration Guide.
This section describes preliminary Frame Relay configuration tasks that are necessary to support VoFR:
Before configuring a Frame Relay DLCI for voice traffic, you must create a Frame Relay map class and configure it to support voice traffic. Configuring a Frame Relay map class is required because the voice bandwidth and fragmentation size attributes are configured on the map class. These attributes are required for sending voice traffic on the PVC.
This section is divided into the following procedures:
A map class applies to a single DLCI or to a group of DLCIs, depending on how the class has been applied to the virtual circuit. If you have a large number of PVCs to configure, you can assign the PVCs the same traffic-shaping properties without statically defining the values for each PVC. You can create multiple map classes with different variables for each map class.
To configure a Frame Relay map class to support voice traffic on a single DLCI or a group of DLCIs, use the following commands, beginning in global configuration mode:
To configure the map class to support FRF.12 fragmentation, see the "Configure a Frame Relay Map Class to Support FRF.12 Fragmentation (Required)" section. To configure the map class to support traffic shaping if you want to send both voice traffic and data traffic on the same PVC, see the "Configure a Service Policy for Traffic-Shaping Parameters for Use on a Map Class (Optional)" section.
Calculating Voice Bandwidth for FRF.11
The frame-relay voice-bandwidth map-class command is used to configure how much bandwidth is reserved for voice traffic. If not enough reserved voice bandwidth remains on the PVC, then any new call attempted will be rejected.
When you consider the amount of voice bandwidth to allocate to voice, your overall bandwidth calculation must include the voice packetization overhead and not just the raw compressed speech codec bandwidth. For VoFR voice packets, there are a total of 6 or 7 bytes total overhead per packet (including standard Frame Relay headers and flags). For subchannels (CIDs) less than number 64, the overhead is 6 bytes. For subchannels greater than or equal to number 64, the overhead is 7 bytes. Add one additional byte if voice sequence numbers are enabled in the voice packets.
To determine the required voice bandwidth, use the following calculation:
required_bandwidth = codec_bandwidth * (1 + overhead/payload_size)
This calculation addresses the amount of bandwidth consumed on the physical network interface. This does not necessarily represent the amount of connection bandwidth used within the Frame Relay network itself, which may be higher because of the overhead of switching small packets.
When using 30-millisecond duration voice packets, an approximate rule of thumb is to add 2000 bps overhead to the raw voice compressed speech codec rate. With the 32 kbps G.726 ADPCM speech coder, a 30-millisecond speech frame uses 120 bytes voice payload plus 6 to 7 bytes overhead, and the overall bandwidth requirement is around 34 kbps for each call.
The codec command is configured as part of the dial peer configuration procedures in the Appendix section of this document.
To configure the map class to support FRF.11, use the following commands to configure a service policy and apply this service policy in map-class configuration mode:
To configure the map class to support FRF.12 fragmentation, use the following command in map-class configuration mode:
router(config-map-class)# frame-relay fragment fragment_size
This command configures Frame Relay fragmentation for the map class. The fragment_size defines the payload size of a fragment, and excludes the Frame Relay headers and any Frame Relay fragmentation header. The valid range is from 16 to 1600 bytes, and the default is 53.
The fragment_size should be less than or equal to the MTU size.
Set the fragmentation size such that the largest data packet is not larger than the voice packets.
To configure the map class to support traffic shaping if you want to send both voice traffic and data traffic on the same PVC, see the next section, "Configure a Service Policy for Traffic-Shaping Parameters for Use on a Map Class (Optional)" section of this document.
When you configure a Frame Relay PVC to support voice traffic, you must ensure that the carrier can accommodate the traffic rate or profile transmitted on the PVC. If too much traffic is sent at once, the carrier might discard frames, which causes disruptions to real-time voice traffic. The carrier might also deal with traffic bursts by queuing up the bursts and delivering them at a metered rate. Excessive queuing also causes disruption to real-time voice traffic.
To compensate for this condition, traffic shaping is required if you are sending both voice traffic and data traffic over the same PVC.
 |
Note When you configure the outgoing Excess Burst size, the Committed Burst size, and the committed information rate (CIR) values, obtain the appropriate values from your carrier. The values configured on the router must match those of the carrier. Traffic shaping is necessary to prevent your carrier from discarding Discard Eligible (DE) bits on ingress or to prevent excessive burst data from affecting voice quality. |
Use the following commands to configure shaping parameters for Cisco 7500 routers with a VIP:
For additional information on the shape command, see the Distributed Traffic Shaping feature module on CCO.
If your shape configuration is complete, see the "Verifying Your Frame Relay Configuration" section. To begin your dial peer configuration, see Appendix section of this document.
To create a service policy for FRF.11 and FRF.12, enter the following commands:
| Command | Purpose | |
|---|---|---|
| Step 1 | ||
| Step 2 | Specifies the match criterion. IP precedence matching is the most commonly used match criterion for FRF.12. For FRF.11, the match protocol vofr command is the required match criterion. |
|
| Step 3 | ||
| Step 4 | ||
| Step 5 | Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. In this example, the class-name was defined in Step 1. |
|
| Step 6 | Reserves a priority queue for CBWFQ traffic. For information on the priority command, see the Low Latency Queueing for the V ersatile Interface Processor document on CCO. |
|
| Step 7 | ||
| Step 8 | ||
| Step 9 | ||
| Step 10 |
Specifies the name of a predefined class, which was defined with the class-map command, included in the service policy. |
|
| Step 11 | Shapes traffic to the indicated bit rate according to the algorithm specified. |
|
| Step 12 | Specifies the name of a previously configured service policy to use in the new service policy. For purposes of FRF.11 and FRF.12, the policy-name is specified in Step 10. |
|
| Step 13 | ||
| Step 14 | ||
| Step 15 | Creates a map class name you will assign to a group of PVCs. The map class name must be unique. |
|
| Step 16 | Router(map-class)# service-policy [ input | output] policy-map-name |
Specifies the name of the service policy to be attached to the interface. |
You can check the validity of your Frame Relay configuration by performing the following tasks:
Posted: Thu Jan 16 00:37:40 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.