Specifications

162 IBM Voice Over Frame Relay Perform Guide
Next to consider are the traffic classes that will be used to give bandwidth
preference to the voice traffic over data. Traffic class definitions need only be
defined if both voice and data will be multiplexed over the same PVC since traffic
classes do not interfere or interrupt each other across circuits. Voice should
normally be given priority over any other traffic type for a PVC. This can be
defined in two different ways:
1. Assign all protocols to the same traffic class assigning voice traffic by its
protocol class VoFR, to the highest priority in that traffic class.
2. Create a super traffic class and assign voice to it. Assign the other protocols to
different traffic classes assigning bandwidth percentages to each class as
required. The super class does not have a bandwidth percentage assigned to
it. Traffic queued in this class will be sent before data in any other traffic class.
Using multiple traffic classes allows you to give preference to high priority
protocols without starving out lower priority protocols.
BRS circuit classes may also be necessary to give bandwidth preference to PVCs
carrying voice over those carrying only data. Circuit class definitions are only
necessary when the sum of the CIRs for the circuits on the interface exceeds the
access rate of the link. If the CIR total does not exceed the access rate, then the
bandwidth percentages assigned to the circuit classes are not used as the FR
traffic shaping function (for example, CIR monitoring) will override the circuit class
bandwidth allocations. If the CIR total does exceed the access rate, then circuit
classes should be defined with those PVCs carrying voice having higher
bandwidth percentages than those carrying data only.
5.2 Tuning the 9783 for a Voice over Frame Relay Network
To achieve higher packaging efficiencies of voice packets (that is, to increase the
payload of frame relay packets relative to the overhead), the voice port frame
packing feature may be used. A single vocoder packet can be embedded into a
frame relay packet for transmission over the WAN. However, due to the small size
of the vocoder packets, which range in size from 9 bytes for 4.8 kbps E-CELP to
60 bytes for 32 kbps ADPCM, the resulting frame relay packets will have high
overhead. See Figure 55 for the simplified format of the frame relay frame.
Figure 55. Simplified Frame Format of Frame Relay Protocol
Because increasing the packet size can increase end-to-end transit time, the
packing feature enables the networking specialist to trade off packaging
efficiency against transit latency. By using the frame packing feature, the
networking specialist can change the default value of one vocoder packet per
frame to a selectable range of two to five vocoder packets. This increases
bandwidth efficiency and data throughput on the WAN. However, for WAN
implementations that experience round-trip delays on the order of 250
milliseconds or more, the networking specialist must ensure that the longer
system delays associated with frame packing do not perceivably affect telephony
performance.