Downloads |
Table Of Contents
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring the Bandwidth Limiting Factor
Monitoring and Maintaining IP RTP Priority
Virtual Template Configuration
Multilink Bundle Configuration
IP RTP Priority
This feature module describes IP RTP Priority. It includes the following sections:
•
Supported Standards, MIBs, and RFCs
•
Feature Overview
The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic.
Note
The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of User Datagram Protocol (UDP)/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first—that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.
The IP RTP Priority feature does not require that you know the port of a voice call. Rather, the feature gives you the ability to identify a range of ports whose traffic is put into the priority queue. Moreover, you can specify the entire voice port range—16384 to 32767—to ensure that all voice traffic is given strict priority service. IP RTP Priority is especially useful on slow-speed links whose speed is less than 1.544 Mbps.
This feature can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; packets in the priority queue are always serviced first.
•
•
Because voice packets are small in size and the interface also can have large packets going out, the Link Fragmentation and Interleaving (LFI) feature should also be configured on lower speed interfaces. When you enable LFI, the large data packets are broken up so that the small voice packets can be interleaved between the data fragments that make up a large data packet. LFI prevents a voice packet from needing to wait until a large packet is sent. Instead, the voice packet can be sent in a shorter amount of time.
How IP RTP Priority Works
If you want to understand its behavior and properly use the IP RTP Priority feature, it is important to consider its admission control and policing characteristics. When you use the ip rtp priority command to configure the priority queue for voice, you specify a strict bandwidth limitation. This amount of bandwidth is guaranteed to voice traffic enqueued in the priority queue. (This is the case whether you use the IP RTP Priority feature with CBWFQ or WFQ.)
Note
IP RTP Priority closely polices use of bandwidth for the priority queue, ensuring that the allocated amount is not exceeded in the event of congestion. In fact, IP RTP Priority polices the flow every second. IP RTP Priority prohibits transmission of additional packets once the allocated bandwidth is consumed. If it discovers that the configured amount of bandwidth is exceeded, IP RTP Priority drops packets, an event that is poorly tolerated by voice traffic. (Enable debugging to watch for this condition.) Close policing allows for fair treatment of other data packets enqueued in other CBWFQ or WFQ queues. To avoid packet drop, be certain to allocate to the priority queue the most optimum amount of bandwidth, taking into consideration the type of codec used and interface characteristics. IP RTP Priority will not allow traffic beyond the allocated amount.
It is always safest to allocate to the priority queue slightly more than the known required amount of bandwidth. For example, suppose you allocated 24 kbps bandwidth, the standard amount required for voice transmission, to the priority queue. This allocation seems safe because transmission of voice packets occurs at a constant bit rate. However, because the network and the router or switch can use some of the bandwidth and introduce jitter and delay, allocating slightly more than the required amount of bandwidth (such as 25 kbps) ensures constancy and availability.
The IP RTP Priority admission control policy takes RTP header compression into account. Therefore, while configuring the bandwidth parameter of the ip rtp priority command you only need to configure for the bandwidth of the compressed call. For example, if a G.729 voice call requires 24 kbps uncompressed bandwidth (not including Layer 2 payload) but only 12 kbps compressed bandwidth, you only need to configure a bandwidth of 12 kbps. You need to allocate enough bandwidth for all calls if there will be more than one call.
The sum of all bandwidth allocation for voice and data flows on the interface cannot exceed 75 percent of the total available bandwidth. Bandwidth allocation for voice packets takes into account the payload plus the IP, RTP, and UDP headers, but again, not the Layer 2 header. Allowing 25 percent bandwidth for other overhead is conservative and safe. On a PPP link, for instance, overhead for Layer 2 headers assumes 4 kbps. The amount of configurable bandwidth for IP RTP Priority can be changed using the max-reserved-bandwidth command on the interface.
If you know how much bandwidth is required for additional overhead on a link, under aggressive circumstances in which you want to give voice traffic as much bandwidth as possible, you can override the 75 percent maximum allocation for the bandwidth sum allocated to all classes or flows by using the max-reserved-bandwidth command. If you want to override the fixed amount of bandwidth, exercise caution and ensure that you allow enough remaining bandwidth to support best-effort and control traffic, and Layer 2 overhead.
As another alternative, if the importance of voice traffic far exceeds that of data, you can allocate most of the 75 percent bandwidth used for flows and classes to the voice priority queue. Unused bandwidth at any given point will be made available to the other flows or classes.
Benefits
Provides Strict Priority Service
The strict priority queueing scheme allows delay-sensitive data such as voice to be dequeued and sent first—that is, before packets in other queues are dequeued. Delay-sensitive data is given preferential treatment over other traffic.
Restrictions
Because the ip rtp priority command gives absolute priority over other traffic, it should be used with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all the excess traffic is dropped.
The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface.
Related Features and Technologies
The IP RTP Priority feature is related to the following features:
•
•
•
•
Related Documents
•
•
•
Supported Platforms
•
•
•
•
•
•
•
•
•
•
•
•
•
This feature runs on the platforms listed. However, it is most useful on voice supported platforms, such as the Cisco 2600 series, Cisco 3600 series, Cisco 7200 series, and Cisco 7500 RSP series.
Supported Standards, MIBs, and RFCs
MIBs
This feature supports no new MIBs.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
None
Standards
None
Prerequisites
To use this feature, you should be familiar with the following:
•
•
•
•
•
•
Configuration Tasks
See the following sections for configuration tasks for the IP RTP Priority feature. Each task in the list indicates if the task is optional or required.
•
•
•
Configuring IP RTP Priority
To reserve a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports, use the following command in interface configuration mode:
Reserves a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports.
Note
The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface.
Configuring the Bandwidth Limiting Factor
To change the maximum reserved bandwidth allocated for CBWFQ and the IP RTP Priority feature, use the following command in interface configuration mode:
Changes the maximum configurable bandwidth for CBWFQ and IP RTP Priority. The default is 75 percent.
Verifying IP RTP Priority
To see the contents of the priority queue (such as queue depth and the first packet queued), use the following command in EXEC mode:
Displays fair queueing configuration and statistics for a particular interface.
Monitoring and Maintaining IP RTP Priority
To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use one or more of the following commands in EXEC mode:
Configuration Examples
This section provides the following configuration examples:
•
•
CBWFQ Configuration
The following example first defines a CBWFQ configuration and then reserves a strict priority queue:
! The following commands define a class map:router(config)# class-map class1router(config-cmap)# match access-group 101router(config-cmap)# exit! The following commands create and attach a policy map:router(config)# policy-map policy1router(config-pmap)# class class1router(config-pmap-c)# bandwidth 3000router(config-pmap-c)# queue-limit 30router(config-pmap-c)# random-detectrouter(config-pmap-c)# random-detect precedence 0 32 256 100router(config-pmap-c)# exitrouter(config)# interface Serial1router(config-if)# service-policy output policy1! The following command reserves a strict priority queue:router(config-if)# ip rtp priority 16384 16383 40The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.
Virtual Template Configuration
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.
router(config)# multilink virtual-template 1router(config)# interface virtual-template 1router(config-if)# ip address 172.16.1.1 255.255.255.0router(config-if)# no ip directed-broadcastrouter(config-if)# ip rtp priority 16384 16383 25router(config-if)# service-policy output policy1router(config-if)# ppp multilinkrouter(config-if)# ppp multilink fragment-delay 20router(config-if)# ppp multilink interleaverouter(config-if)# max-reserved-bandwidth 80router(config-if)# endrouter(config)# interface Serial0/1router(config-if)# bandwidth 64router(config-if)# ip address 1.1.1.2 255.255.255.0router(config-if)# no ip directed-broadcastrouter(config-if)# encapsulation ppprouter(config-if)# ppp multilinkrouter(config-if)# end
Note
Multilink Bundle Configuration
The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces.
The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.
router(config)# interface multilink 1router(config-if)# ip address 172.17.254.161 255.255.255.248router(config-if)# no ip directed-broadcastrouter(config-if)# ip rtp priority 16384 16383 200router(config-if)# no ip mroute-cacherouter(config-if)# fair-queue 64 256 0router(config-if)# ppp multilinkrouter(config-if)# ppp multilink fragment-delay 20router(config-if)# ppp multilink interleaverouter(config-if)# max-reserved-bandwidth 80The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:
router(config)# interface multilink 2router(config-if)# ip address 172.17.254.162 255.255.255.248router(config-if)# no ip directed-broadcastrouter(config-if)# ip rtp priority 16384 16383 100router(config-if)# no ip mroute-cacherouter(config-if)# fair-queue 64 256 0router(config-if)# ppp multilinkrouter(config-if)# ppp multilink fragment-delay 20router(config-if)# ppp multilink interleaveIn the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1.
router(config)# interface serial 2/0router(config-if)# bandwidth 256router(config-if)# no ip addressrouter(config-if)# no ip directed-broadcastrouter(config-if)# encapsulation ppprouter(config-if)# no ip mroute-cacherouter(config-if)# no fair-queuerouter(config-if)# clockrate 256000router(config-if)# ppp multilinkrouter(config-if)# multilink-group 1Next, serial interface 2/1 is configured to be part of multilink bundle 2.
router(config)# interface serial 2/1router(config-if)# bandwidth 128router(config-if)# no ip addressrouter(config-if)# no ip directed-broadcastrouter(config-if)# encapsulation ppprouter(config-if)# no ip mroute-cacherouter(config-if)# no fair-queuerouter(config-if)# clockrate 128000router(config-if)# ppp multilinkrouter(config-if)# multilink-group 2Debug
The following example shows a sample output from the debug priority command:
Router# debug priority*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.699:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.711:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.719:WFQ:dropping a packet from the priority queue 64In this example, 64 indicates the actual priority queue depth at the time the packet was dropped.
Command Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
ip rtp priority
To reserve a strict priority queue for a set of Real-Time Transport Protocol (RTP) packet flows belonging to a range of User Datagram Protocol (UDP) destination ports, use the ip rtp priority interface configuration command. To disable the strict priority queue, use the no form of this command.
ip rtp priority starting-rtp-port-number port-number-range bandwidth
no ip rtp prioritySyntax Description
Defaults
This command has no default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command is most useful for voice applications, or other applications that are delay-sensitive.
This command extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of UDP/RTP ports whose voice traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first—that is, before packets in other queues are dequeued. We recommend that you use the ip rtp priority command instead of the ip rtp reserve command for voice configurations.
This command can be used in conjunction with either Weighted Fair Queueing (WFQ) or Class-Based WFQ (CBWFQ) on the same outgoing interface. In either case, traffic matching the range of ports specified for the priority queue is guaranteed strict priority over other CBWFQ classes or WFQ flows; voice packets in the priority queue are always serviced first.
•
•
Keep the following guidelines in mind when configuring the bandwidth parameter:
•
•
•
•
Examples
The following example first defines a CBWFQ configuration and then reserves a strict priority queue with the following values: a starting RTP port number of 16384, a range of 16383 UDP ports, and a maximum bandwidth of 40 kbps.
! The following commands define a class map:class-map class1match access-group 101exit! The following commands create and attach a policy map:policy-map policy1class class1bandwidth 3000queue-limit 30random-detectrandom-detect precedence 0 32 256 100exitinterface Serial1service-policy output policy1! The following command reserves a strict priority queue:ip rtp priority 16384 16383 40Related Commands
max-reserved-bandwidth
To change the percent of interface bandwidth allocated for Class-Based Weighted Fair Queueing (CBWFQ) and IP RTP Priority, use the max-reserved bandwidth interface configuration command. To restore the default value, use the no form of this command.
max-reserved-bandwidth percent
no max-reserved-bandwidthSyntax Description
Defaults
75 percent
Command Modes
Interface configuration
Command History
Usage Guidelines
The sum of all bandwidth allocation on an interface should not exceed 75 percent of the available bandwidth on an interface. The remaining 25 percent of bandwidth is used for overhead, including Layer 2 overhead, control traffic, and best-effort traffic.
If you need to allocate more than 75 percent for CBWFQ and IP RTP Priority, you can use the max-reserved- bandwidth command. The percent argument specifies the maximum percentage of the total interface bandwidth that can be used by CBWFQ classes and IP RTP Priority.
If you do use the max-reserved-bandwidth command, care should be taken not to take too much bandwidth away from best-effort and control traffic when using this command.
The max-reserved-bandwidth command can be used only on interfaces; it cannot be used on virtual circuits (VCs).
Examples
In the following example, the policy1 policy map is configured for three classes with a total of 8 Mbps configured bandwidth, as shown in the output from the show policy-map command:
Router# show policy-map policy1Policy Map policy1Weighted Fair QueueingClass class1Bandwidth 2500 (kbps) Max Threshold 64 (packets)Class class2Bandwidth 2500 (kbps) Max Threshold 64 (packets)Class class3Bandwidth 3000 (kbps) Max Threshold 64 (packets)When the service-policy output command is entered in an attempt to attach the policy map on a 10 Mbps Ethernet interface, an error message such as the one shown below is produced:
I/f Ethernet1/1 class class3 requested bandwidth 3000 (kbps) Available only 2500 (kbps)The error message is produced because the default maximum configurable bandwidth is 75 percent of the available interface bandwidth, which in this example is 7.5 Mbps. To change the maximum configurable bandwidth to 80 percent, use the max-reserved-bandwidth command in interface configuration mode:
max-reserved-bandwidth 80service output policy1endTo verify that the policy map was attached, enter the show policy-map interface command:
Router# show policy-map interface e1/1Ethernet1/1 output :policy1Weighted Fair QueueingClass class1Output Queue:Conversation 265Bandwidth 2500 (kbps) Packets Matched 0 Max Threshold 64 (packets)(discards/tail drops) 0/0Class class2Output Queue:Conversation 266Bandwidth 2500 (kbps) Packets Matched 0 Max Threshold 64 (packets)(discards/tail drops) 0/0Class class3Output Queue:Conversation 267Bandwidth 3000 (kbps) Packets Matched 0 Max Threshold 64 (packets)(discards/tail drops) 0/0Virtual Template Configuration Example
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum bandwidth allocated between CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.
multilink virtual-template 1interface virtual-template 1ip address 172.16.1.1 255.255.255.0no ip directed-broadcastip rtp priority 16384 16383 25service-policy output policy1ppp multilinkppp multilink fragment-delay 20ppp multilink interleavemax-reserved-bandwidth 80endinterface Serial0/1bandwidth 64ip address 10.1.1.2 255.255.255.0no ip directed-broadcastencapsulation pppppp multilinkend
Note
Related Commands
Glossary
CBWFQ—Class-Based Weighted Fair Queueing. Extends the standard WFQ functionality to provide support for user-defined traffic classes.
Class-Based Weighted Fair Queueing—See CBWFQ.
PPP—Point-to-Point Protocol. Successor to SLIP that provides router-to-router and host-to-network connections over synchronous and asynchronous circuits. Whereas SLIP was designed to work with IP, PPP was designed to work with several network layer protocols, such as IP, IPX, and ARA. PPP also has built-in security mechanisms, such as CHAP and PAP. PPP relies on two protocols: LCP and NCP.
RTP—Real-Time Transport Protocol. One of the IPv6 protocols. RTP is designed to provide end-to-end network transport functions for applications sending real-time data such as audio, video, or simulation data over multicast or unicast network services. RTP provides services such as payload type identification, sequence numbering, time-stamping, and delivery monitoring to real-time applications.
SNA—Systems Network Architecture. Large, complex, feature-rich network architecture developed in the 1970s by IBM. Similar in some respects to the OSI reference model, but with a number of differences.
UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768.
Weighted Fair Queueing—See WFQ.
WFQ—Weighted Fair Queueing. Congestion management algorithm that identifies conversations (in the form of traffic streams), separates packets that belong to each conversation, and ensures that capacity is shared fairly between these individual conversations. WFQ is an automatic way of stabilizing network behavior during congestion and results in increased performance and reduced retransmission.
