Specifications

© Copyright IBM Corp. 2000 157
Chapter 5. Performance Tuning, and Monitoring
This chapter deals with the performance tuning and monitoring of the 2212 IBM
Access Utility and IBM 9783 for voice over frame relay networks.
5.1 Tuning IBM 221X Routers for a Voice over Frame Relay Network
Through the use of statistical multiplexing, frame relay networks provide an
excellent transport medium for data but represent somewhat of a challenge for
voice. The transit delay for each packet forwarded through a frame relay network
is potentially different from that of the previous packet. And although frame relay
networks ensure proper sequencing of frames, they do not ensure delivery of all
packets; retry and recover are left to higher layers. The overall delay of a given
packet can be due to a number of factors, but it is mostly affected by the amount
of additional network traffic present when the packet is being forwarded. There is
a general rule of thumb that the round-trip response time for a voice packet
should not exceed 250 milliseconds; otherwise, the callers will begin talking over
one another. Your router network can be tuned to minimize the transient delay of
voice packets to maximize the quality of the voice calls.
There are a number of configurations that can be used to support VoFR and each
requires different tuning considerations. Frame relay fragmentation plays a key
role in this if the voice will be carried over relatively slow (for example, 64 kbps)
links. Other key factors are the CIR and committed burst size, BRS traffic classes
and allowable queue depths, the number of global buffers created, and the
number of receive buffers allocated to each interface.
5.1.1 Tuning Frame Relay Interfaces
Fragmentation is required for all PVCs on any interface that will be used for voice
or any other high priority, real-time data. There are two types of fragmentation:
end-to-end and interface (or UNI/NNI). Interface level fragmentation has not been
implemented by any major FR switch vendors and so it is not available through
any FR service providers. Per the Frame Relay Forum implementation
agreement, FRF.12, end-to-end fragmentation is only supported for PVCs.
Therefore, an interface with voice support should not be used to support FR
SVCs.
Fragmentation is necessary to minimize the amount of delay in queuing and
transmitting voice packets. Fragmentation should be used for all PVCs that
exchange data over an interface supporting voice. This means that a router that
does not support voice would still need to do fragmentation if it communicates
with another router that is supporting voice over the same interface.
Fragment sizes may vary between FR interfaces depending on the access speed
of the link, the CIR of the PVC, and whether this interface is actually carrying
voice or just communicating with another router whose interface is carrying voice.
Fragment sizes are not negotiated or communicated between interfaces and
therefore may be different for two interconnected PVCs. Because of the overhead
associated with fragmentation, it is best to keep the fragment size as large as
possible while still maintaining high quality voice communications. The most
important thing to remember is the 250-millisecond round-trip delay limit. That