background image
4-24
Cisco AVVID Network Infrastructure Enterprise Quality of Service Design
956467
Chapter 4 QoS in an AVVID-Enabled Wide-Area Network
QoS Recommendations for WAN Aggregation Routers
ISDN Recommendations
When designing VoIP over ISDN networks, remember the following:
·
Link bandwidth varies as B channels are added or dropped.
·
RTP packets may arrive out of order when transmitted across multiple B channels.
·
CAC limitations with Call Manager locations-based CAC.
Variable Bandwidth
ISDN allows B channels to be added or dropped in response to the demand for bandwidth. The fact that
the bandwidth of a link varies over time presents a special challenge to the CBWFQ/LLQ queuing
mechanisms of IOS. Prior to IOS 12.2(2)T, a policy-map implementing LLQ could only be assigned a
fixed amount of bandwidth. On an ISDN interface, IOS assumes that only 64 kbps is available, even
though the interface has the potential to provide 128 kbps, 1.544 Mbps, or 2.408 Mbps of bandwidth. By
default, the maximum bandwidth assigned must be less than or equal to 75% of the available bandwidth.
Hence, prior to IOS 12.2(2)T, only 75% of 64 kbps, or 48 kbps, could be allocated to an LLQ on any
ISDN interface. If more was allocated, then an error message was generated when the policy-map was
applied to the ISDN interface. This severely restricted the number of VoIP calls that could be carried.
The solution to this problem was introduced in IOS 12.2(2)T with the introduction of the percent
keyword to the priority statement. This keyword allows for the reservation of a variable bandwidth
percentage to be assigned to the LLQ.
MLP Packet Reordering Considerations
MLP LFI is used for fragmentation and interleaving voice and data over ISDN links. LFI fragments large
data packets into smaller fragments and transmits them in parallel across all the B channels in the bundle.
At the same time, voice packets are interleaved in between the fragments, thereby reducing their delay.
The interleaved packets are not subject to MLP encapsulation. They are encapsulated as regular PPP
packets. Hence, they have no MLP sequence numbers and cannot be reordered should they arrive out of
sequence. The need to reorder the packet is quite likely. The depth of the various link queues in the
bundle may differ, causing RTP packets to overtake each other as a result of the difference in queuing
delay. The various B channels may also take different paths through the ISDN network and end up with
different transmission delays.
This reordering of packets is not generally a problem for RTP packets. The buffers on the receiving VoIP
devices will reorder the packets based on the RTP sequence numbers. However, reordering does become
a problem if cRTP is used. The cRTP algorithm assumes that RTP packets are compressed and
decompressed in the same order. If they get out of sequence, then decompression will not occur
correctly. Therefore, today it is not safe to use cRTP if there is more then one B channel in the MLP
bundle. The same restriction applies if you are using MLP over ATM or Frame Relay, in which case
cRTP is not possible if there is more then one VC in the bundle.
A solution to the reordering problem is offered by Multiclass Multilink PPP (MCMP). With MCMP, the
interleaved packets are given a small header with a sequence number, which allows them to be reordered
by the far end of the bundle before cRTP decompression takes place. At the time of this writing, MCMP
is not yet supported in IOS.
CallManager CAC Limitations
IP telephony in branch networks are typically based on the centralized call-processing model and use
locations-based CAC to limit the number of calls across the WAN. Locations-based CAC does not
currently have any mechanism for tracking topology changes in the network. So if the primary link to a